How do you protect sensitive government or defense source code built by contractors?

A government department commissions a system: fraud detection for tax returns, a logistics planner, an analytics tool for an internal security team. A large system integrator wins the contract. They bring in two subcontractors for parts of the work.

Over three years, the code passes through dozens of people. Developers from three companies. Staff officers who rotate every two years. A support vendor who maintains it after go live.

The rules say code must stay on approved machines. In practice, developers copy it to test, to debug, to work on a deadline. When the contract moves to a new integrator, the old one is asked to hand over and delete everything.

Every company and person who works on the system has held a full, readable copy of it. Contractors finish, subcontractors are replaced, staff are posted elsewhere, and their copies are not tracked.

The rules that detect fraud, the logic that plans movements, the way a system scores risk: once known, they can be studied, worked around or sold. A readable copy can also be given to an AI tool to explain, summarise or rebuild in hours.

Logic meant to stay hidden, like detection rules or planning methods, becomes known to people outside the organisation. A change of contractor carries the risk of the old one keeping everything. After an incident, there is no record of who held which code and when.

Security clearances and NDAs say who is allowed to see the code, but do not stop a cleared person copying it. Approved machines and secure rooms say where work should happen, but not about copies made for testing, debugging or deadlines.

Handover and deletion at contract end cover the repositories the contractor manages, not laptops, subcontractors or ex staff. Audits find problems later, but do not prevent the copy.

NakodaX is installed on your own servers and works offline, including on air gapped networks. The keys and licences stay inside your environment.

Most of the system is boilerplate: screens, logins, forms, reports, connections to other systems. The sensitive logic, the rules that make the system do its job, sits separately in its own files. NakodaX scans the repository and suggests those files. Your team reviews the list and decides what to protect.

Integrators and subcontractors work on a protected copy, where the locked files are replaced by stand ins. A stand in takes the same inputs as the real code and gives back a result, so they can build and test the rest of the system. The sensitive logic is not inside it.

When someone needs to change the sensitive code, they ask for a change session. A second admin approves, the window has an end date, and every step is logged. When a contractor leaves, the locked files on their machines cannot be read or run without a key from your own NakodaX server.

NakodaX does not change your original repository. It builds a new, protected repository next to it, where the files that hold your business logic are locked and replaced by stand ins. The protected repository keeps no history of those files, so earlier versions of the protected code are not in it and cannot be recovered from it.

To get the benefit, your team runs a switch over: every integrator, subcontractor and member of staff stops working in the original repository and moves to the protected one. Once they are cut off from the original, all new work happens against stand ins.

Copies made before the switch are not changed. Anyone who already holds a readable copy of the code still has it. NakodaX protects from the day you switch: new versions, new contractors, and every handover after it.

People who open the real files in an approved change session can read them during that window. NakodaX keeps that to a few named people, with a record. It cannot stop someone remembering what they saw.

Files you did not lock stay readable. Today it works with Python, JavaScript, TypeScript and SQL.