NakodaX

Source Protection/Approved changes

Changes to the crown jewels need a second pair of eyes.

Someone asks. A second admin approves. The window has an end. When the work is done, the code locks again.

How a change session works.

A change session is a time limited, approved window in which a developer can edit the real protected code on one branch. A second admin must approve it, it covers a set number of machines, and when the work is done the code is locked again and the whole thing is on record.

Someone asks

A developer or an admin asks for a session on a branch.

A second admin approves

A different admin approves after entering their password. Nobody can approve their own request.

The approver also sets how many machines the session covers.

Unlock, edit, lock

The developer unlocks the files, makes the change, tests it and locks them again. The session cannot be closed until the code is locked.

On record

Every request, approval and close is logged, so you can show who changed what and when.

Who uses it.

  • Security teams who want two people on every change

    No lone edit to the code that matters.

  • Engineering leads protecting pricing or scoring logic

    Changes come with an approver, a time limit and a record.

  • Companies preparing for a customer security review

    Show exactly who can change the crown jewels and how.

Approved changes questions

Can a developer approve their own session?
No. A different admin has to approve it.
What happens when the session ends?
The extra access ends, and a process that was using it stops at its next check.
Can the code be left unlocked by mistake?
A session cannot be closed until the code is locked again, and a warning shows while files are unlocked.

Ship the software. Keep the secret.

Tell us what you deploy and where it needs to run. We will show you how it would work. Already a customer? Sign in to your console.