Why Software Releases Need Two-Person Approval
New software can be released to thousands, or even millions of users in minutes. That speed is enabled through automated pipelines, which also introduce risk. It can be as simple as a hacked account, a misconfiguration, or an update of a malicious package that ends up in production before it is known. If the software needs two people to approve, it provides a conscious point before software gets to customers.
When talking about How to prevent software supply chain attacks, the emphasis is on scanning tools, signatures, and build provenance. While those controls are important, software supply chains rely on human authority. Two-person approval minimizes the risk of a trusted release being published by a single individual identity, error, or dishonest employee.
One Account Should Not Control the Entire Release
A perilous software workflow can be defined as a workflow where the same person or account writes the code, approves the changes, and publishes the final product. This results in one point of failure.
If an attacker gets access to that account, they can modify the source code, modify the build process, and publish a malicious package without any additional access. The resulting software can still be from the right repository and via the organization’s regular distribution channels.
These powers are separated by two-person approval. The release may be made by one person, but released by another authorized person, reviewing for accuracy. This doesn’t render compromise unattainable, but it does require an attacker to overcome an extra identity and control. This is already the case in financial systems, where a payment could be created by one person and authorized by another.
Reviewers Can Catch Changes Automation Misses
Automated security tools can be helpful to identify known vulnerabilities, exposed secrets, and suspicious dependencies. But they don’t always know if a change is a good thing in the context of the broader application.
A reviewer might find that a release contains an unplanned package, alters the publishing target, or alters permissions for no apparent reason. They might notice that a build process has been changed to push data to a new external service.
Each of these changes may not activate a scanner, since they would be technically valid actions. Human review provides context that automated checks may not have.
The second approver is not to just click on a button. They must be able to see release notes, code changes, test results, dependency changes, and build evidence to make an informed decision.
Two-Person Approval Limits Insider Risk
Not all software supply chain attacks are launched by an outside attacker. An employee, maintainer, or contractor who has legitimate access to the computer system can intentionally insert harmful code.
If one person can release software on their own, the organization is very dependent on their behavior. Two-person approval also provides accountability and makes it more difficult to avoid detection of deliberate abuse.
The control is especially important for code-signing operations, package publication and changes to CI/CD infrastructure. These activities can impact all downstream customers using the software.
Approval records are also useful for investigations. Organizations can be assured who prepared the release, who authorized it, and what evidence was reviewed at the time.
Automation Can Preserve Development Speed
One of the main concerns is that it will delay releases. This can occur where the process relies on informal communication or involves manually checking each minor change with senior staff.
The better way is to integrate approval into the release process. After automated tests, vulnerability scans and policy checks are successful, the system can ask for approval from an approved reviewer. It only gets released once that other identity confirms it.
Different risk rules can be applied as well. A minor internal update might demand a standard peer review, but for a public package, a security product, or a critical infrastructure component, more stringent approval and signing operations might be called for.
There should be a well-defined exception process for emergency releases. In the event of a bypass, it should be documented and limited access and review should be provided following deployment.
Independence Matters More Than Two Clicks
If both Approvals are granted by the same person, then two-person approval offers little security. It is also weak if reviewers automatically approve changes without reviewing them.
The approver should be someone other than the person who prepares the release. They should be strongly authenticated and approval should be logged.
In highly sensitive releases, code review and artifact signing may also need to be done separately. One team can accept the changes in the sources and a protected signing service will sign the final build only if all the necessary checks pass. This establishes a number of trust boundaries instead of depending on a single workflow.
A Simple Control With Significant Value
Two-person approval is no substitute for secure coding, dependency scanning, isolated builds, or digital signatures. It enhances those controls and makes it harder for anyone to make a change into an official release.
This way, accidental updates, compromised credentials, and malicious insider activity are not accepted in production. It also establishes a path of accountability.
With the rapid pace of software releases and the number of users involved, no single user or account should have absolute control. Two-person approval adds a little friction at the ‘public mistake’ stage. In software supply chain security, that friction can be one of the most valuable controls an organization can add.
