SSDF and Code Signing: How Software Producers Prove Secure Development to Federal Buyers

Federal agencies increasingly depend on software developed and maintained by third-party producers. As a result, federal buyers need more than assurance that a software product works as intended. They also need confidence that the software was developed, built, tested, and released using secure practices.

For software producers, this means being able to demonstrate how security is incorporated throughout the software development lifecycle.

The NIST Secure Software Development Framework (SSDF) provides a common language for doing this. NIST SP 800-218 defines a set of high-level secure software development practices that can be integrated into existing development lifecycles. NIST also describes SSDF as a common vocabulary that software purchasers and producers can use when communicating about secure development practices.

Federal software security guidance has evolved. OMB Memorandum M-26-05, Adopting a Risk-Based Approach to Software and Hardware Security, issued in January 2026, rescinded OMB Memorandum M-22-18 and M-23-16. Under the updated approach, software security attestations are optional and driven by individual agency risk assessments and requirements. Agencies may continue using the Secure Software Development Attestation Form and may also establish software security requirements through contracts. Software producers should therefore understand the specific evidence and assurance requirements of each federal customer rather than assume that a single attestation requirement applies universally.

This is where code signing becomes an important part of the conversation.

Code signing does not prove that an organization follows every SSDF practice. A digital signature primarily provides assurance about the integrity of signed code and the identity or source associated with the signature. NIST explains these functions in Security Considerations for Code Signing (NIST Cybersecurity White Paper 5, or NIST CSWP 5), which describes code signing as a mechanism for providing data integrity and source authentication.

Together, SSDF and code signing help software producers connect secure development practices with verifiable controls over software integrity and release activities.

However, a properly governed code-signing process can generate valuable operational evidence.

When signing keys are protected, signing access is restricted, approvals are enforced, signing is integrated into CI/CD pipelines, certificates are managed centrally, and signing events are recorded, software producers can demonstrate that the software-release process is controlled and auditable.

The distinction is important:

Code signing is not a replacement for SSDF. It is one technical control that can support secure software development and provide evidence about the integrity and governance of software releases.

This article explores how SSDF and code signing work together, what federal buyers may expect from software producers, what evidence organizations should maintain, and how centralized code signing can strengthen the secure software supply chain.

Understanding how SSDF and code signing work together helps software producers demonstrate secure development and maintain confidence in their software releases.

What Is the NIST Secure Software Development Framework?

The Secure Software Development Framework (SSDF) is a set of high-level practices developed by NIST to help organizations integrate security into their software development lifecycle.

Rather than requiring organizations to replace their existing SDLC methodology, SSDF can be incorporated into development models such as Agile, CI/CD, and other development approaches.

NIST SP 800-218, Version 1.1, organizes secure software development practices into four groups. NIST published an initial public draft of SSDF Version 1.2 (SP 800-218 Rev. 1) in December 2025, proposing updated practices to address evolving software security needs. The draft emphasizes continuous improvement of secure development processes and reliable software updates, reinforcing that security must be maintained as software evolves rather than treated as a one-time activity.

The four practice groups in SSDF Version 1.1 are:

Practice Group	Focus
Prepare the Organization (PO)	Prepare people, processes, and technology for secure software development. PO.5 specifically addresses the security of software development environments.
Protect the Software (PS)	Protect code and software releases against unauthorized access and tampering. Practices PS.1 through PS.3 address protecting software, maintaining the integrity of release artifacts, and archiving and protecting software releases.
Produce Well-Secured Software (PW)	Develop, build, test, and verify secure software
Respond to Vulnerabilities (RV)	Identify, assess, and respond to vulnerabilities

The framework addresses security throughout the software lifecycle rather than focusing only on the final application. It considers the people, processes, development environments, source code, build activities, release artifacts, and vulnerability-response practices that collectively influence software security.

For example, an organization may have strong vulnerability scanning but still have weaknesses in its source-code repository, build infrastructure, dependency management, or release process. SSDF provides a structured way to examine these activities together and identify gaps that could undermine the security of the final product.

Understanding SSDF and Code Signing together helps software producers identify how signing controls contribute to specific secure development practices.

For federal software producers, this common vocabulary is particularly valuable because it helps organizations map their internal processes to recognized secure development practices and communicate their approach to federal purchasers. As SSDF continues to evolve, the draft Version 1.2 guidance also highlights the importance of reviewing and improving those processes over time and delivering software updates reliably and securely.

Why Federal Buyers Care About Secure Software Development

Federal agencies face supply-chain risks because software often comes from multiple external producers and suppliers. Weaknesses in development or release processes can affect the security of government systems.

Executive Order 14028, Improving the Nation’s Cybersecurity, increased federal focus on software supply-chain security. NIST subsequently published Software Supply Chain Security Guidance Under EO 14028 Section 4e, outlining secure development practices and supporting evidence.

Executive Orders 14144 (January 2025) and 14306 (June 2025) further changed federal cybersecurity policy. In January 2026, OMB Memorandum M-26-05 rescinded M-22-18 and M-23-16, introducing a risk-based approach to software and hardware security. Agencies may still use the CISA Secure Software Development Attestation Form and the Repository of Software Attestations and Artifacts (RSAA) voluntarily, but requirements now vary by agency and contract.

Software producers must be prepared to explain:

• How is the software developed securely?
• How are development environments protected?
• How are vulnerabilities identified?
• How are software releases controlled?
• How are signing keys protected?
• Who can authorize a production release?
• How can the organization demonstrate what happened during a release?

These questions highlight the importance of code signing. A well-governed signing process helps protect software integrity, restrict unauthorized signing, and provide auditable evidence of controlled software releases.

By aligning SSDF and Code Signing practices, software producers can provide stronger evidence of how security controls are applied during software development and release.

What Does Code Signing Prove?

Code signing uses public-key cryptography to create a digital signature over software. When a recipient verifies the signature, it can provide assurance that the signed artifact has not been modified after signing and associate the signature with the signing identity. NIST describes these as two core purposes of code signing: data integrity and source authentication.

This is one of the key ways SSDF and Code Signing complement each other: SSDF guides secure development, while digital signatures help verify the integrity and origin of released software.

In the context of SSDF and Code Signing, digital signatures provide an important mechanism for verifying software integrity and authenticating the signing source.

For example, a software producer may sign an executable before distributing it to customers. The customer or operating system can check:

• Whether the digital signature is valid and the software remains unchanged.
• Whether the signing certificate chains to a trusted certificate authority and identifies the expected publisher.
• Whether the certificate has been revoked, using mechanisms such as Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP)
• Whether a trusted timestamp establishes that the signature was applied while the signing certificate was valid.

Platforms also use their own security mechanisms. Windows SmartScreen evaluates an application’s reputation and other signals to help warn users about potentially unsafe or unrecognized downloads. macOS Gatekeeper checks whether downloaded software meets Apple’s security requirements, including code-signing and notarization checks where applicable.

These checks make code signing an important software supply-chain security control. However, their exact behavior depends on the platform, certificate type, trust configuration, and verification policy.

A valid signature does not prove that the software was securely developed.

A legitimate signing key can still be abused if an attacker compromises the build or release environment and gains access to the signing process. Therefore, effective code-signing security depends not only on the cryptographic signature but also on how signing keys, access, approvals, and release infrastructure are governed.

Why a Valid Signature Is Not Enough

Code signing helps verify software integrity and authenticate its publisher, but it cannot guarantee that the software itself is safe. If an attacker compromises the development or build environment before signing, malicious code may become part of the final artifact and still receive a valid signature. This highlights why code signing must be supported by secure build infrastructure, restricted access, and controlled release processes.

Consider a simplified software development process:

Source Code → Build → Test → Sign → Release

If an attacker compromises the build environment and modifies the software before signing, the resulting artifact could be malicious even though its signature is legitimate. The certificate may not be forged, the cryptographic algorithm may work correctly, and the signing operation may be authorized. The failure occurs because an attacker has compromised the process responsible for producing the release.

The SolarWinds supply-chain compromise illustrates this risk. Attackers compromised the software build environment and inserted malicious code into the Orion software build process. The affected updates were then distributed with legitimate digital signatures, making the incident a clear example of why a valid signature alone cannot establish that software was developed securely.

This is why SSDF and Code Signing must work together with secure build environments, access restrictions, and controlled release procedures.

A mature code-signing implementation must therefore protect the entire signing workflow, not just the private key. Essential safeguards include hardware-backed private-key protection, strong user authentication, role-based access control, multi-person approval workflows, secure CI/CD integration, certificate lifecycle management, signing-event logging, continuous monitoring, and incident response procedures. Together, these controls help prevent unauthorized users or compromised systems from abusing a legitimate signing identity to distribute malicious software.

How SSDF and Code Signing Work Together

Code signing does not satisfy SSDF on its own, but it can support specific secure software development objectives by helping protect software integrity, control release activities, and maintain auditable evidence.

Secure Development Objective	Code Signing Contribution	Relevant SSDF Practice
Protect software from unauthorized modification	Digital signatures help recipients verify artifact integrity.	PS.2.1
Establish software source	Signing certificates associate artifacts with a signing identity.	PS.2.1
Protect release processes	Signing can be restricted to approved release workflows.	PS.3
Protect signing credentials	Hardware security modules (HSMs) can protect private signing keys.	PO.5, PS.1
Restrict privileged operations	Role-based access control (RBAC) limits who can request signatures.	PO.2, PO.5
Enforce approvals	Signing platforms can require authorization before production signing.	PO.2, PS.3
Create evidence	Audit logs record signing events and support traceability.	PO.2, PS.3
Support incident response	Centralized certificate management can facilitate certificate revocation and replacement.	PS.3, RV
Integrate security into CI/CD	Automated signing can become a controlled stage in the release pipeline.	PS.1, PS.3

These mappings show how code signing can support specific SSDF practices, rather than demonstrate compliance with the entire framework. This makes SSDF and Code Signing complementary approaches to protecting software artifacts and maintaining confidence in the release process. For example, an audit record showing that a production artifact was signed by an authorized identity after the required approval can provide evidence that release activities are controlled and traceable.

The relationship between SSDF and Code Signing becomes particularly important when organizations need to demonstrate how software integrity is maintained throughout the release lifecycle.

The relevant practices address different aspects of security. PO.2 focuses on defining roles and responsibilities, while PO.5 addresses the security of software development environments. PS.1 through PS.3 cover protecting software from unauthorized changes, maintaining the integrity of release artifacts, and archiving and protecting software releases. In particular, PS.2.1 explicitly addresses code signing as a means of protecting software integrity.

The exact mapping depends on how an organization implements each control. Code signing supports the broader SSDF program, but it does not independently prove that every secure development practice has been followed.

By combining SSDF and Code Signing, organizations can connect their secure development policies with practical safeguards that protect software artifacts and release processes.

From “We Sign Code” to “We Can Prove How We Sign Code”

Many organizations already digitally sign their software. However, simply possessing a code-signing certificate does not necessarily represent a mature code-signing program.

Consider a manual signing process in which a developer stores a certificate and private key on a workstation, signs an executable before release, and uploads the result to a distribution system. The organization can truthfully state, “Our software is digitally signed.” However, this statement alone does not explain who performed the signing, whether that person was authorized, how the private key was protected, or whether the correct artifact was approved for release.

Other important questions remain: Can the organization identify all software signed with the certificate? Are signing activities recorded and auditable? What happens if the signing key is compromised?

A centralized and governed signing environment provides stronger answers. It allows the organization to demonstrate that private keys are protected, signing access is restricted, and production signing requires authorization through approved workflows. Centralized certificate management and signing-event logs also help teams investigate historical signing activity and respond to potential security incidents.

This changes code signing from a simple release activity into a controlled, traceable, and auditable security process.

A practical SSDF and Code Signing implementation gives organizations a clearer way to demonstrate these controls to customers and auditors.

Protecting Code Signing Keys

Private signing keys are among the most sensitive assets in the software supply chain. If an attacker obtains a legitimate signing key, they may be able to sign malicious software that appears to come from a trusted publisher. This risk was illustrated in NVIDIA’s 2022 security incident, when leaked code-signing certificates were used to sign malware, and MSI’s 2023 cyberattack, after which reports linked stolen signing keys to maliciously signed firmware. These incidents demonstrate how compromised signing credentials can undermine trust in software distribution.

Storing private keys as ordinary files on developer workstations or shared build servers creates additional exposure because an attacker who compromises the host may be able to access or misuse the key. Hardware security module (HSM)-backed signing provides a stronger model. An HSM generates and protects private keys within a dedicated cryptographic boundary, allowing authorized signing operations without distributing the private key to individual developers. This separates the person or system requesting a signature from the protected key that performs the cryptographic operation.

Strong key protection is essential to SSDF and Code Signing because it helps prevent unauthorized parties from creating signatures that appear to come from a trusted software publisher.

For publicly trusted code-signing certificates, the CA/Browser Forum Code Signing Baseline Requirements have required subscriber private keys to be generated, stored, and used in a suitable hardware cryptographic module since June 1, 2023. The requirements specify acceptable protection methods and cryptographic-module standards, including applicable FIPS 140-2 Level 2 or Common Criteria EAL 4+ criteria for subscriber key protection. Organizations should verify that their selected HSM or signing service meets the applicable requirements rather than assume that any hardware device is sufficient.

For stronger assurance, organizations should select cryptographic modules with the appropriate FIPS 140-2 or FIPS 140-3 validation, according to their security requirements. FIPS validation applies to a specific cryptographic module and its validated configuration, not simply to a vendor or product family. Combined with restricted access, approval workflows, monitoring, and a documented key-compromise response plan, hardware-backed signing helps reduce the risk of signing credentials being stolen or misused.

Key protection is therefore an important part of SSDF and Code Signing because compromised credentials can undermine the integrity of otherwise controlled software releases.

Role-Based Access Control and Approval Workflows

A secure code-signing process should ensure that every person has only the permissions needed for their role, while production signing remains restricted to authorized personnel. Role-based access control (RBAC) and approval workflows help organizations enforce this separation of duties throughout the software release process.

For example, developers may be responsible for building and testing software, release engineers may initiate approved releases, and designated approvers may authorize production signing. Security administrators manage signing policies, certificate administrators oversee certificate lifecycles, and auditors review signing activity. The exact role structure will vary by organization, but the principle remains the same: the person who can modify source code should not automatically have access to production signing keys, and the person requesting a signature should not necessarily be able to approve it.

For high-value or sensitive releases, organizations can introduce M-of-N approval, which requires a predefined number of authorized approvers out of a larger group before signing can proceed. For example, a two-of-three policy requires approval from at least two of three designated approvers. This reduces reliance on a single individual and adds an additional control against unauthorized releases. Organizations should also separate signing keys by product, application, or environment—for example, development, testing, and production—so that a compromised key or workflow does not automatically expose every release.

By enforcing role-based permissions, independent approvals, and key separation through the signing platform, organizations can reduce the risk of unauthorized signing and demonstrate that production releases are governed by controlled, auditable procedures.

These access controls strengthen SSDF and Code Signing practices by ensuring that production signing is performed only through authorized roles and approved workflows.

Integrating Code Signing Into CI/CD

Manual code signing can introduce inconsistencies and make it difficult to demonstrate that every production artifact followed the same security controls. When signing is performed separately at the end of a release, organizations may lack consistent evidence connecting the artifact to its build, security testing, approvals, and release authorization. Integrating code signing into the continuous integration and continuous delivery (CI/CD) pipeline makes signing a controlled step in the software release process.

A well-designed SSDF and Code Signing approach makes it easier to connect development security checks with authorized signing and release activities.

A governed pipeline can follow this sequence:

Build → Security Testing → Approval → Signing → Release → Deployment Verification

Integrating SSDF and Code Signing into CI/CD helps connect secure development checks with controlled signing and software distribution.

Each stage can enforce defined requirements before the software advances. For example, the pipeline can prevent signing until required security checks pass and authorized personnel approve a production release. The signing system can also record which build was signed, which identity or service requested the operation, and when it occurred.

This approach provides several practical benefits. Consistency comes from applying the same defined workflow and security checks to each production artifact, reducing variation between releases. Reduced key exposure is achieved by keeping private signing keys in a protected signing service or hardware security module (HSM), rather than distributing them to developers or storing them in pipeline scripts. The CI/CD system requests a signing operation through an authorized interface without needing direct access to the private key.

Traceability improves when signing events are linked to build identifiers, artifact hashes, approvals, and release records. These records help teams establish which artifact was signed and investigate unexpected changes or suspicious releases. Automation reduces repetitive manual steps, which can lower the risk of human error and make release procedures more repeatable. Automation should still operate within defined permissions and approval requirements; it should not mean that every build can automatically receive a production signature.

Policy enforcement allows the pipeline to block signing when required conditions have not been met, such as failed security tests, missing approvals, or an unauthorized release request. Organizations can also use artifact hashing to verify that the file being signed is the intended build output. Where supported, hashing and signing can be performed within the controlled build environment so that sensitive artifacts do not need to be sent to an unrelated external service. The hash must be calculated and checked consistently against the exact artifact being signed; hashing alone does not protect the artifact unless the result is securely bound to the signing and verification process.

Security controls should continue after signing. At deployment, the receiving system or deployment pipeline should verify the signature, validate the certificate chain and relevant trust or revocation information, and confirm that the artifact has not changed since it was signed. Where applicable, it should also check the trusted timestamp and enforce the organization’s release policy. A valid signature helps establish integrity and signing identity, but it does not by itself prove that the software is free of vulnerabilities or was developed securely.

For software producers seeking to demonstrate secure-development practices to federal buyers, integrating signing and verification into CI/CD creates a more consistent and auditable release process. Build records, security-test results, approval evidence, signing logs, and deployment-verification results can collectively help demonstrate that release controls are implemented in practice rather than existing only as documented procedures.

What Evidence Should Software Producers Maintain?

Federal software buyers may request additional evidence based on a product’s risk and criticality. Software producers should maintain records that demonstrate how their secure-development and release controls operate in practice. This evidence can help establish how software is built, signed, verified, and managed throughout its lifecycle.

Maintaining this evidence helps organizations demonstrate how SSDF and Code Signing controls are implemented throughout the software release lifecycle.

Signing Event Records

Signing logs should record the artifact hash, certificate used, requesting identity, timestamp, approval details, and signing result. These records help trace each signature to a specific artifact and authorized release.

Where applicable, organizations should use RFC 3161 trusted timestamping through a trusted Time-Stamping Authority (TSA). A trusted timestamp can help establish that a signature existed while its certificate was valid, even after expiry. However, it does not automatically preserve trust after certificate revocation.

Certificate Inventory

Organizations should track which certificates exist, who owns them, which products use them, their expiry dates, and whether they are active or revoked. Under CA/Browser Forum requirements, publicly trusted code-signing certificates issued from March 1, 2026, are limited to a maximum validity of 460 days, making regular renewal planning and certificate inventory updates increasingly important.

Access Records

Access records should show who can request, approve, and perform signing operations. Maintaining permission records and approval histories helps demonstrate that production signing is restricted and responsibilities are appropriately separated.

Key-Protection Documentation

Documentation should describe how private keys are generated, stored, protected, accessed, rotated, and retired. It should also identify the cryptographic hardware or signing service used and the controls that prevent unauthorized signing.

Signed SBOMs and Build Provenance Attestations

A software bill of materials (SBOM) identifies software components and dependencies in a release, helping teams assess vulnerabilities and component origins. Signing the SBOM helps recipients verify its integrity. Build provenance attestations record how an artifact was produced, including relevant build processes and environments, helping establish its origin.

Incident-Response Procedures

The response plan should explain how to investigate a suspected signing-key compromise, restrict further use, and revoke affected certificates when appropriate. It should also cover identifying affected releases, rebuilding and re-signing software where necessary, notifying customers, and preserving evidence for investigation.

Together, these records create an evidence trail that helps software producers demonstrate how they protect signing keys, control releases, verify software integrity, and respond to security incidents.

Code Signing and the Broader Software Supply Chain

Code signing is an important part of software supply chain security, but it cannot protect every component involved in producing and delivering software. Modern applications may include proprietary code, open-source dependencies, third-party libraries, container images, build tools, CI/CD systems, and externally maintained packages. A weakness in any of these components can introduce risk, even when the final software artifact has a valid signature.

Organizations therefore need complementary controls to understand what their software contains, identify vulnerabilities, protect the build process, and verify where artifacts originate. Key measures include software bills of materials (SBOMs), vulnerability scanning, dependency management, secure build environments, source-code protection, security testing, and vulnerability disclosure processes.

Each control addresses a different security question. An SBOM identifies the components and dependencies included in a software release, helping teams assess the impact of newly discovered vulnerabilities. Vulnerability scanning and dependency management help identify known security issues and keep third-party components appropriately maintained. Secure build environments and source-code protection reduce the risk of unauthorized changes to source code, build tools, or release processes.

Artifact provenance provides evidence about how and where software was built, including information about the build process and its environment. Frameworks and tools such as SLSA (Supply-chain Levels for Software Artifacts), in-toto, and Sigstore can support provenance generation, verification, and transparency. These approaches complement code signing by helping organizations assess an artifact’s origin and the integrity of the process that produced it.

Code signing addresses a related but distinct question: Was the artifact signed by an identity trusted by the verifier, and has the signed content changed? Signature verification helps detect unauthorized modifications after signing, but a valid signature alone does not prove that the software was built securely or is free from vulnerabilities.

NIST recommends automatically verifying hashes or signatures for vendor-supplied software and updates where feasible. Combined with dependency analysis, security testing, provenance evidence, and secure build practices, code signing becomes one layer in a broader defense-in-depth strategy for protecting the software supply chain.

An effective SSDF and Code Signing strategy therefore works alongside SBOMs, vulnerability management, and build provenance to provide broader software supply chain assurance.

Together, SSDF and Code Signing help organizations combine secure development practices with mechanisms for verifying software integrity and release authenticity.

Building an-Ready Code Signing Program

Organizations can strengthen their code-signing environment through a phased approach that combines technical safeguards, documented procedures, and verifiable evidence. Each step should help establish not only that a control exists, but also that it operates consistently and supports relevant NIST Secure Software Development Framework (SSDF) practices.

An effective SSDF and Code Signing strategy should combine technical safeguards, documented policies, and evidence that signing controls operate consistently.

Step 1: Inventory Certificates and Keys

Identify all code-signing certificates, private keys, signing systems, products, and CI/CD pipelines. Record certificate owners, expiration dates, key locations, and associated applications to uncover unmanaged credentials and establish a baseline for risk assessment.

Step 2: Assess Key Protection

Determine whether private keys are stored as exportable files on workstations or servers or protected by hardware security modules (HSMs) or an appropriately secured signing service. Review key access, backup, and recovery procedures, and document how the organization prevents unauthorized signing or key extraction.

Step 3: Define a Signing Policy

Document which artifacts may be signed, which certificates are approved for each use, who can request and authorize signing, and what security checks must pass first. Define separate requirements for development, testing, and production releases, including additional approvals for sensitive or high-impact software.

Step 4: Implement Role-Based Access Control (RBAC)

Assign permissions according to job responsibilities, separating development, release initiation, approval, and signing administration where practical. For high-value releases, require multiple independent approvals where appropriate, and periodically review access rights to remove unnecessary privileges.

Step 5: Centralize Signing

Move production signing away from individual developer workstations and uncontrolled scripts into a governed signing service or protected cryptographic infrastructure. Enforce authentication, authorization, approval policies, and audit logging at the signing boundary so that only approved requests can use production keys.

Step 6: Integrate Signing With CI/CD

Make signing a defined stage in the release pipeline, following required builds, security tests, and approvals. Bind signing to the intended artifact using cryptographic hashes and ensure the pipeline records the build identity and signing result. At deployment, verify signatures and relevant certificate trust information before accepting the artifact.

Step 7: Centralize Audit Logs

Collect signing requests, approvals, identities, timestamps, certificate details, and outcomes in a protected, centralized logging system. Restrict access to these records and monitor for unusual activity, such as unexpected signing requests or repeated failures. Retain the evidence according to organizational and contractual requirements so release activity can be reconstructed during an audit or investigation.

In an SSDF and Code Signing program, centralized audit records help connect each software release to its signing identity, approval history, certificate, and corresponding artifact.

Step 8: Map Controls to SSDF

Map implemented signing controls to relevant SSDF practices and document the evidence supporting each mapping. For example, key protection and controlled signing access support protection against unauthorized changes, while release records and approvals help demonstrate controlled release practices. Treat the mapping as a documented rationale for how controls support SSDF objectives, rather than assuming that deploying a signing tool alone proves compliance.

This mapping helps organizations demonstrate how SSDF and Code Signing controls work together to protect software throughout development and release.

Step 9: Test the Process

Periodically test whether unauthorized users can initiate signing, whether approval requirements can be bypassed, whether private keys remain protected, and whether compromised certificates can be revoked effectively. Exercise the incident-response process, including identifying affected releases, re-signing where necessary, and notifying customers. Record test results, remediation actions, and follow-up verification to show that the controls work as intended.

Step 10: Prepare for Post-Quantum Cryptography (PQC)

Assess how future quantum-resistant signature algorithms could affect signing systems, certificate infrastructure, software update mechanisms, and signature verification across supported products. Inventory cryptographic dependencies and identify systems that may require changes to signing tools, formats, firmware, or trust stores.

For applicable U.S. National Security Systems, CNSA 2.0 identifies LMS, XMSS, and ML-DSA as approved options for software and firmware signing, subject to the relevant implementation and validation requirements. NSA’s transition guidance includes a 2030 milestone for quantum-resistant software and firmware signing in applicable national-security contexts; organizations should consult the requirements relevant to their systems rather than treating this as a universal deadline for every software producer. Early compatibility testing and a documented migration roadmap can reduce future disruption.

Including post-quantum readiness in an SSDF and Code Signing strategy can also help organizations prepare their signing infrastructure for future cryptographic requirements.

Taken together, these steps turn code signing from an isolated technical function into a governed, testable process. By retaining evidence of key protection, access controls, release approvals, signature verification, and periodic testing, software producers can better demonstrate how their signing practices support secure development and release assurance.

How Can Software Producers Prepare for Federal Buyers?

Organizations preparing to sell software to federal agencies should begin by mapping their existing development practices to SSDF. They should then identify where operational evidence exists and where gaps remain.

Reviewing SSDF and Code Signing controls together can help software producers identify weaknesses in key protection, release authorization, artifact verification, and auditability before engaging with federal customers.

For code signing, this means asking:

• Are production signing keys protected?
• Can developers directly access private keys?
• Is signing centrally controlled?
• Are production signing permissions restricted?
• Are approval workflows enforced?
• Is signing integrated into CI/CD?
• Are certificates centrally tracked?
• Are signing events logged?
• Can historical signing activity be reconstructed?
• Is there a documented response to key compromise?

If the answer to these questions is unclear, the organization may have a gap between its documented security practices and its ability to demonstrate those practices. That gap is precisely what mature software security programs should address.

How Encryption Consulting Can Help

Encryption Consulting’s CodeSign Secure provides centralized code-signing infrastructure to help organizations strengthen the security and governance of their software-signing processes. It helps bring signing keys, certificates, access permissions, approval workflows, and audit activity under centralized control, reducing reliance on fragmented or manually managed signing practices.

For organizations strengthening SSDF and Code Signing practices, CodeSign Secure provides a centralized approach to managing signing operations and maintaining evidence of release activity.

CodeSign Secure supports integration with hardware security modules (HSMs) and cloud HSM environments to protect private signing keys. Supported HSM technologies include Thales Luna, Entrust, Utimaco, and Securosys, helping organizations use dedicated cryptographic infrastructure to safeguard signing credentials. Centralized role-based access control and approval workflows can also help separate development, release initiation, approval, and administration responsibilities.

The platform can integrate with CI/CD environments such as Azure DevOps, Jenkins, and GitLab CI, making code signing part of a controlled software-release workflow. Client-side hashing can help verify artifact integrity within the originating environment and reduce the need to transfer artifacts elsewhere for hashing. Timestamping can provide evidence of when a signature was created, supporting long-term signature validation subject to the applicable certificate and revocation policies.

CodeSign Secure also supports centralized certificate lifecycle management, helping teams track certificates and manage renewals. Centralized audit logs and SIEM integration can help security teams monitor signing activity, investigate suspicious events, and incorporate signing-related events into their broader security monitoring processes.

As organizations prepare for post-quantum cryptography, support for algorithms such as ML-DSA and LMS can also help them evaluate and plan for quantum-resistant code-signing approaches, subject to applicable standards, product configurations, and deployment requirements.

CodeSign Secure can help organizations implement and demonstrate controlled, repeatable, and auditable signing practices that support their broader secure software development and software supply chain security programs.

Conclusion

Federal software producers need to demonstrate how they secure software throughout its lifecycle, not simply state that security practices are in place. NIST’s SSDF provides a framework for these practices, while federal requirements and agency-specific guidance determine the evidence and controls expected from software suppliers.

A well-governed code-signing program helps address this challenge by protecting signing keys, enforcing access controls and approvals, integrating signing into CI/CD pipelines, managing certificates, and maintaining audit records. These measures help organizations establish a controlled and traceable release process while supporting their broader secure software development and supply chain security objectives. Integrating SSDF and Code Signing gives software producers a practical way to strengthen release governance and demonstrate the effectiveness of their security controls.

By integrating code signing with SSDF-aligned practices and using Encryption Consulting’s CodeSign Secure, software producers can strengthen release integrity, improve accountability, and provide federal buyers with clearer evidence of how software is protected from development through distribution.

Frequently asked questions

What are software artifacts?

Software artifacts are files, packages, and other outputs created or used during the software development lifecycle. Examples include source code, compiled binaries, libraries, container images, installers, configuration files, and test reports. In the context of SSDF and Code Signing, protecting these artifacts helps maintain software integrity throughout development and distribution.

What are the most common types of software artifacts?

Common software artifacts include source code, executable files, software libraries, application packages, container images, installation files, configuration files, documentation, and test reports. SSDF and Code Signing practices help organizations manage and protect these different artifact types during development and release.

What is a build artifact in CI/CD?

A build artifact is an output generated when source code is processed through a build pipeline. It may be a binary, executable, package, or container image. Integrating SSDF and Code Signing into CI/CD workflows helps ensure that artifacts are tested, approved, signed, and verified before deployment.

Why is software artifact management important?

Software artifact management helps organizations maintain version control, traceability, reproducibility, and integrity. As part of an SSDF and Code Signing strategy, these practices help teams identify unauthorized changes, investigate security incidents, and ensure that the correct software versions are distributed.

How does code signing protect software artifacts?

Code signing uses digital signatures to help verify the identity of the signing source and detect modifications made after signing. Within SSDF and Code Signing practices, it provides an important layer of assurance about artifact integrity and authenticity, although it does not independently prove that software was developed securely.