Protect The Software

Expanded Definition

“Protect the Software” is the SSDF practice area focused on preserving the confidentiality and integrity of code, build pipelines, and release artefacts. It is about preventing unauthorised access, silent modification, and malicious substitution before software reaches users.

The term covers more than source-code permissions. It includes how repositories are authenticated, how build systems are isolated, how signing keys are protected, and how release packages are verified before publication. In practice, the boundary is between software that is still being shaped and software that is about to be trusted by downstream systems.

A common misunderstanding is to treat protection as only a developer access problem. In reality, build servers, artifact stores, signing services, dependency pipelines, and release automation all sit inside the trust path. If one layer is weak, tampering can flow forward even when the code repository itself is well controlled.

For release integrity and provenance, SLSA is a useful reference point because it frames software protection as a supply-chain integrity problem, not just a source control problem.

Examples and Use Cases

Protect the Software appears wherever teams need to keep development and delivery assets trustworthy:

• Restricting source repositories so only approved contributors can change production-bound code.
• Separating build infrastructure from general-purpose admin access so a compromised workstation does not become a release path.
• Signing release artefacts and checking signatures before deployment to detect tampering.
• Storing build secrets, tokens, and certificates in controlled systems rather than embedding them in code or pipeline files.
• Verifying dependency provenance so a package swap or poisoned component does not enter the build unnoticed.

These use cases often trade convenience for assurance. Faster delivery pipelines are attractive, but as automation increases, the trust placed in every intermediate system also increases. The practical challenge is keeping release velocity without turning build infrastructure into a single point of compromise.

Control authors often describe this area alongside secure development, build integrity, and release governance because the same attack can affect all three stages at once.

Security Implications

When Protect the Software is weak, attackers do not need to attack the final product directly. They can alter the software before it ships, which makes the compromise harder to detect and far more scalable than a one-off endpoint intrusion.

Typical failure conditions include exposed credentials in build jobs, overly broad access to repositories, unverified artefacts, and weak separation between development and production release paths. Once an attacker can change code, inject dependencies, or replace a signed package, the resulting trust failure can spread to every consumer of that release.

For practitioners, the most important symptom is usually not obvious malware in the codebase. It is unexpected change in a place that should have been tightly controlled, such as a pipeline step, a release artefact, or a signing workflow. That is why software protection has to be validated across the full delivery chain, not only at the commit stage.

NHIMG research on non-human identities shows how common secret leakage and excessive privilege are in modern environments, which matters here because CI/CD systems and release automation frequently rely on machine credentials. Those exposures can turn ordinary delivery tooling into a path for unauthorised code publication.

Security, Operational and Governance Implications

Protecting software is both a technical control and a governance responsibility. It determines who can alter trusted releases, how build integrity is proven, and which teams own the trust boundary between source, build, and deployment.

Operationally, this means software delivery cannot be treated as a low-friction utility. Teams need clear ownership for signing keys, release approvals, pipeline hardening, and exception handling when a build or artefact fails verification. The governance question is simple: if the release path is compromised, who can prove what changed and when?

In practice, the strongest programs treat software protection as part of resilience. If provenance, access control, or artefact verification fails, the organisation needs a way to stop distribution quickly and rebuild trust without guessing which component was altered.

Related resources from NHI Mgmt Group

• How should security teams protect code signing keys used for firmware and software updates?
• Why do software-based MFA methods still fail to protect high-risk AI access?
• Why do software publishers need code signing certificates to protect trust in distributed code?
• What are the signs that an SCA programme is failing to protect the software supply chain?