Why Vannevar Labs FDEs need TS/SCI: their code runs on classified clouds

In Vannevar Labs’ job ad for a Forward Deployed Engineer, the hardest requirement has nothing to do with Python or Kubernetes. Candidates must hold an active US Top Secret clearance and be SCI-eligible. That is a condition for being considered at all, not a nice-to-have.

At a glance it looks like the usual administrative barrier of the defence industry. Read the FDE ad alongside three of the company’s other engineering ads, though, and the picture sharpens. They need clearance because the software runs on classified clouds, and engineers have to put the code there themselves.

You may never apply to a US defence company, but Vannevar shows what FDE work looks like when the customer’s environment is as tightly controlled as it gets.

Many other industries run controlled environments, just less strictly: banks, hospitals, government agencies anywhere. Anyone who wants to be an FDE in those places should understand this kind of work.

Clearance follows the server, not the job title

Vannevar describes itself as a company building AI systems for the US Department of War, the new name for the Department of Defense. By early 2023 its main product, Decrypt, was running at more than 15 military bases. Its customer, put simply, is the military.

The ad for the Full Stack Engineer (FDE/ATO) role describes the task as bringing a complex microservice architecture running on Kubernetes onto classified cloud environments.

Engineers also have to provide direct, “hands on keyboard” support when software is deployed on classified networks. The wording suggests that whoever deploys usually works directly on the classified side, rather than only operating remotely.

The Senior Software Engineer (ATO) ad names two environments specifically: IL6 and JWICS. So the clearance is tied to where the software runs, not to the title on an employee badge.

Nor does the role stop at deployment. The FDE ad in Oahu says the hire will be the technical owner of a mission and of the customer engagements attached to it.

They design, build and take responsibility for software that runs directly in the customer’s environment. The company also says its engineers, product team and CTO go straight to where problems arise, including to units in Ukraine.

Documentation is a deliverable too

The biggest difference from an FDE at a SaaS company is the volume of compliance work. The Oahu ad asks for experience developing and deploying software under the RMF (Risk Management Framework), the process software must pass to be authorised to run on US Department of Defense systems.

The FDE/ATO ad asks for the implementation of key security controls to meet Department of Defense accreditation standards.

The Senior Software Engineer (ATO) ad spells out the paperwork: deployment runbooks, the System Security Plan and CONOPS. Here documentation is something to deliver, just like code. Without the documents the software is not authorised, and without authorisation it does not run.

Picture a request that sounds simple: add a feature that pulls data from a government data platform and displays it to analysts.

At a SaaS company this might take a few days: call the API, build the UI, merge, deploy. The Oahu ad lists exactly the systems you would have to touch: data platforms, IdAM providers, SIEM and cross-domain solutions (CDS).

In this hypothetical scenario, users have to sign in through the government’s identity system, not yours. Every access has to send logs to a SIEM that the customer monitors.

If data has to move between two networks at different classification levels, it has to go through a CDS, and the System Security Plan and runbooks have to be updated accordingly. The code itself might still take only a few days; the integration and documentation will most likely take up most of the time.

Who this job ad rules out

The word “active” in the clearance requirement is the most important detail. Anyone without a current clearance does not qualify, however strong technically. Clearance is not something you can pick up after joining, so the role is all but closed to engineers coming from a purely commercial background.

The second excluded group is harder to spot: engineers who have only deployed SaaS on commercial clouds, where everything is automated and documentation is an afterthought. They may pass a Kubernetes interview. But a role that demands RMF experience, working knowledge of IdAM, SIEM and CDS, and writing a System Security Plan is likely to expose the gaps quickly.

The third group is people who cannot travel. The FDE role is listed as fully remote but requires travel, possibly 20-30% of the time, to meet the people in charge of missions. “Remote” here does not mean staying at home.

The table below combines requirements from the four ads, what each means in day-to-day work, and its equivalent in heavily regulated industries outside defence.

Requirement in the ads	What it means in the job	Equivalent outside defence
Active TS/SCI clearance	Permission to work on the classified side to deploy	Access to the customer’s production environment, with background checks
Deploy to classified clouds (IL6, JWICS)	Bringing Kubernetes microservices into isolated networks	On-prem or air-gapped installs at banks and hospitals
RMF compliance, implementing security controls	Software must be authorised before it can run	Security audits and risk assessments before go-live
Runbooks, System Security Plan, CONOPS	Documentation is a deliverable	Operations and security architecture documents for the customer’s IT team
Integrating IdAM, SIEM, CDS	Using the customer’s infrastructure, not your own	Integrating enterprise SSO, sending audit logs to the monitoring system

The skills you can take with you

Most readers will not qualify for this particular role, and do not need to. What is worth learning is the capability the ads implicitly demand: getting software into an environment that is not yours, under someone else’s rules, then proving in writing that everything is secure.

An FDE working for a bank or a health agency needs exactly the same capability, even if the controls are usually lighter.

The hardest part for people used to SaaS is deploying without Internet access and without their own infrastructure. Practising that is far closer to the real job than any Helm tutorial.

On your CV, do not bury compliance experience in a line such as “familiar with security”. State which identity systems you integrated, where you sent audit logs, and which documents you wrote for which audit, then prepare an example for each row in the last column of the table above before the interview.

A US TS/SCI clearance is specific to this role. Writing a runbook that a stranger can follow, on someone else’s system, is a skill every heavily regulated customer needs.