By NakodaX Engineering team
NakodaX · · Updated
NakodaX blog/Source Protection·2 min read
How do you give contractors access to sensitive code without giving them all of it?
Protect the files that carry your business logic and give contractors stand in copies of them. A stand in has the same interface as the real file, so the contractor builds and tests as normal. If they must change the real code, a change session needs a second person's approval and ends on its own.
Contractors can build everything around the key logic without ever holding it.
On this page
A contractor joins to build the checkout, the reports or the integrations. They need to run the product and test their work. They do not need to read your pricing engine.
With ordinary access, they get everything. Over time the code passes through several companies and people, and nobody can say who still holds what.
What does a contractor need to do the job?
Most of the code around the key logic is ordinary: screens, logging, login, configuration, database access. A contractor can work on that without ever reading the files that carry the advantage. What they need is something that behaves like those files, so their own work runs and tests.
What are stand ins?
Source Protection creates a stand in for each protected file when it publishes the release. A stand in has the same interface as the real file, with the function bodies replaced by placeholders. It is the same idea as mocking a payment provider when you test.
Contributors get a developer license. It opens the stand ins and never the real code. On every key request NakodaX decides whether a machine gets the real code or the stand in, so the choice is not left to the machine.
What happens when they need the real code?
Sometimes a contractor must change the protected code itself. That happens in a change session: a time limited window on a branch, with a record of everything done in it.
The developer requests the session. A different person on your team approves it after entering their password again. Nobody can approve their own request. The approver also sets how many machines the session covers. NakodaX refuses to seal if an unlocked file is staged in git, so readable code does not end up in a commit. When the session ends, the extra access ends with it.
What does this not do?
It does not make the real code unreadable to someone approved to change it, and a running licensed machine holds the code in memory. It works today for Python, JavaScript, TypeScript and SQL. The story of contractors on sensitive code shows how a government team uses it.
The takeaway
Give contractors stand ins, and keep the real code behind an approved, time limited change session.
Related product
NakodaX Source Protection
Let vendors and customers build or run software without receiving selected proprietary source code in readable form.
See how it worksCommon questions
What is a stand in for protected code?
A copy of a protected file with the same interface and placeholder function bodies. Developers build and test against it without reading the real code.
Who approves a change to the real code?
A different person on your team approves a change session after entering their password again. Nobody can approve their own request.
Which languages does Source Protection support?
Python, JavaScript, TypeScript and SQL today. Others are planned, with no dates.
