The Framework
P-SSCRM organizes software supply chain security into Groups, each broken into Practices, each broken into Controls. Use the tree on the left to jump straight to what you need, or click a Practice below to open its Controls. Every code badge (like G.1.1) is a permalink — click it to jump there and grab the link from your address bar.
Assessment questions
Every control below carries a short set of questions under an "Assessment questions" heading. Search for a control below, or click Expand all, then work through the questions with your team for an informal, qualitative assessment — there is no score. For a formal, interview-based assessment, see Measure and Improve.
Perform compliance 5 controls
Develop security policies 6 controls
Manage suppliers 5 controls
Training 3 controls
Assess and manage risk 4 controls
Develop security requirements 2 controls
Build security in 6 controls
Manage component and container choices 4 controls
Discover vulnerabilities 5 controls
Manage vulnerable components and containers 2 controls
Safeguard artifact integrity 6 controls
Safeguard build integrity 8 controls
Secure software development environment 10 controls
- E.3.1 Authentication
- E.3.2 Environmental separation
- E.3.3 Role-based access control
- E.3.4 Information flow enforcement
- E.3.5 Baseline configuration
- E.3.6 Monitor changes to configuration settings
- E.3.7 Boundary protection
- E.3.8 Key rotation
- E.3.9 Ephemeral credentials
- E.3.10 Establish a root of trust
Respond to/disclose vulnerabilities 5 controls
Monitor intrusions/violations 2 controls
Identify SSC Control Gaps 5 controls
No controls match that search.
Governance G
G.1 Perform compliance
5
G.1.1 Organizational security requirements
Organizational security requirements, such as those imposed by standards and regulations, are included in the SDLC.
Identify, document, communicate, and maintain security requirements and policies for the organization's software development infrastructure, including all AI models used, and secure SDLC. Maintain the requirements and policies over time. Incorporate constraints imposed by standards and regulations and customer-driven security requirements.
Assessment questions
- How do you document and share a secure SDLC that the engineers are aware of?
- How do you define security requirements and policies for the organization, its development infrastructure, contributions, and processes?
- How are these requirements and contributions maintained over time?
- How are constraints imposed by regulatory and compliance drivers included in these requirements, policies, and the SDLC?
Standard mappings
- EO 4e(ix)
- SSDF PO.1.1
- SSDF-AI PO.1.1, PO.1.2
- BSIMM CP1.1, CP1.2, CP1.3, SE3.9, SR1.1, SR2.2, SR3.3
- 800-161 SA-15
- CNCF-SSC SC-CE: Establish and adhere to contribution policies
- SELF-ATTESTATION 2
G.1.2 Software license conflict
Software licenses that conflict with the organization’s policies are identified.
Software licenses may or may not allow certain types of usage, contain distribution requirements or limitations, or require specific action if the software is modified. Risk is increased if the licenses of components conflict with an organization's policies. Software licenses should be documented and tracked to trace the users and use of licenses to access control information and processes according to software usage restrictions. License metadata should be recorded during the build and made available in the SBOM.
Assessment questions
- How do you check that the software licenses for tools or third party components comply with your organization's use policies?
- What tools, if any, do you use to automate the license check process?
- How do you document and track users and uses of software licenses relative to access control policies and software usage restrictions?
Standard mappings
- 800-161 CM-10
- OWASP-SCVS 2.14, 2.15, 5.12
- S2C2F SCA-2
- CNCF-SSC AU: Scan software for license implications, M-A: Managing software licenses
G.1.3 Produce attestation
Produce an audit trail for every step in the build process, the integrity/provenance of training data, and evidence of the use of secure software development practices.
Configure tools to generate attestations (aka evidence) to create an audit trail for every step in the build process and of the use of secure software development practices. These attestations should indicate conformance with record retention requirements, preserve the integrity of the findings and the authenticity of the information. For AI models, generate attestations of the integrity and provenance of the training datasets. Assign responsibility for creating attestations that tools cannot generate. Attestations should be immutable and published in the source repository releases, in the package registry, or elsewhere, with their existence recorded in a transparency log.. An attestation is a signed assertion that the record is trustworthy.
Assessment questions
- Describe your automated or manual processes for producing attestations for the build process, the integrity/provenance of training data, and for the use of secure development practices?
- Where do you publish your attestations, e.g. source repositories, package registries, transparency logs?
- What are your auditability/retention requirements for these attestations?
- How is responsibility assigned for creating needed attestations that tools cannot generate?
- What tools or frameworks (e.g. TUF, in-toto) do you use to produce authenticated attestations?
- What is your rationale for providing self-attestation for your product?
- How do you ensure that the attestations are immutable?
Standard mappings
- EO 4e(i)(F), 4e(ii), 4e(v)
- SSDF PO.3.3
- SSDF-AI PO.3.3
- BSIMM SE3.9, SM1.4, SR1.3
- 800-161 SA-15, AU-2, AU-3, AU-12
- SLSA Producing artifacts
- SELF-ATTESTATION 1f
- CNCF-SSC BP-SA Sign every step in the build process, A-A Use a store to manage metadata from in-toto
G.1.4 Deliver provenance
Enable traceability and reproducibility of the actions performed while writing code, compiling, testing, and deploying software by making transparent the steps that were performed, by whom and in what order.
Automatically collect and provide traceability data for generated products, including AI models, including: what entity built the package, what build process they used, and the top-level inputs to the build, such that the data's traceability can be verified and is generated automatically from the build service using a convention common in the package ecosystem. Provenance SHOULD accompany the artifact at publish time, and package ecosystems SHOULD provide a way to map a given artifact to its corresponding attestations.
Assessment questions
- Describe your manual and/or automated processes for generating provenance data.
- What authentications take place relative to the production of provenance data?
- How is provenance data verified?
- How is the integrity and immutability of provenance data managed?
- What do provenance records include, e.g. the initial state of the machine, VM, or container, and user-specified build steps?
- How do you ensure that access to generated AI models trained on sensitive data (e.g. PII, IP, financial, or other regulated data) is restricted to individuals who already have access rights to the sensitive data or that generated models do not contain sensitive data?
Standard mappings
- EO 4e(vi), 4e(vii), 4e(x)
- SSDF PS.3.2
- SSDF-AI PS.3.2
- SLSA Distributing provenance, Source L3: Signed and auditable provenance
- 800-161 SR-4
- OWASP-SCVS 6.1, 6.2, 6.3, 6.4
- CNCF-SSC A-A Distribute in-toto metadata with TUF, D-V Ensure clients can perform Verification of Artifacts and associated metadata, D-V Ensure clients can verify the freshness of files, D-A Use The Update Framework
- SELF-ATTESTATION 3
ATT&CK techniques
G.1.5 Deliver SBOM
By providing SBOM, enable internal and external customers to analyze the contents of the final software package, including the version of the dependencies.
Generate (preferably during build time) and provide a SBOM (in a machine-readable, NTIA-supported format) for generated products, including AI models. SBOMs should be digitally signed using a verifiable and trusted key. VEX data for all components should also be considered.
Assessment questions
- How do you deliver an SBOM and provenance data that satisfy your contracts with software acquirers, such as in a standard-base format?
- How and when is the SBOM built?
- What tool do you use?
- How do you digitally sign the SBOMs?
- How do you produce a VEX supplement for your SBOM, if any?
- What is your process for generating the VEX information, if any?
Standard mappings
- EO 4e(vi), 4e(vii), 4e(x)
- SSDF PS.3.2
- SSDF-AI PS.3.2
- SLSA Source L3: Signed and auditable provenance
- BSIMM SE3.6
- 800-161 SR-4
- OWASP-SCVS 1.4, 2
- S2C2F REB-3, REB-4
- CNCF-SSC M-V: Generate an immutable SBOM of code
- SELF-ATTESTATION 3
ATT&CK techniques
G.2 Develop security policies
6
G.2.1 Upper management support
Upper management understands the business risks of insecure software and supports the resources necessary for secure software development.
An upper management (e.g., c-suite) leadership team understands the business risk of insecure software development, including AI models used and delivered, and of violating compliance and privacy obligations. The team is responsible for the entire software development process and deploying secure software to production. The commitment of this team is communicated to personnel associated with development-related roles and is backed up by the commitment to allocating adequate resources and making sometimes-difficult business decisions for security over faster release dates.
Assessment questions
- Please describe upper management's commitment to secure software development practices involving AI models.
- In what way is this commitment publicly demonstrated and communicated to development roles and responsibilities?
- Comment on the adequacy of resources dedicated to secure software development.
Standard mappings
- EO 4e(ix)
- SSDF PO.2.3
- SSDF-AI PO.2.3
- BSIMM SM1.3, CP2.5
Roles
G.2.2 Secure SDLC checks
Criteria throughout the SDLC are used to check the software’s security during development.
Define criteria for a secure SDLC and associated software security checks that indicate how effectively software, including AI models, resulting from the SDLC meets the organization's expectations. These checks include key performance indicators (KPI), vulnerability severity scores, and security checks included in the 'definition of done' in an agile process and may be used for go/no-go decisions. The use of automated tools aids thoroughness, objectivity, and efficiency of these checks.
Assessment questions
- What kind of criteria for security checks has been established, such as for security testing results?
- How can these checks indicate if security practices are being used and secure software is being developed?
- How are these checks tracked through the SDLC?
- Are the checks automated or manual?
Standard mappings
- EO 4e(iv), 4e(v)
- SSDF PO.4.1
- SSDF-AI PO.4.1
- BSIMM SM1.4, SM3.3
- 800-161 SA-15
- SELF-ATTESTATION 4
Roles
G.2.3 Roles and responsibilities
Ownership for security controls throughout the SDLC at the organizational level and at the product team- and operational- level are established and visible.
Throughout the organization, create new roles and alter responsibilities for existing roles to incorporate security controls and practices, as appropriate, into the SDLC and to keep management educated and informed on security issues. These roles can be centralized for the organization to promote thought leadership among developers and architects; and distributed throughout the organization in a network of security advocates.
Assessment questions
- What security roles and responsibilities have been created to encompass all parts of the SDLC - both within the development teams as well as at an organizational level?
- What security roles and responsibilities have been created to address AI model acquisition, development, use, and publication?
Standard mappings
- EO 4e(ix)
- SSDF PO.2.1
- SSDF-AI PO.2.1
- BSIMM SM2.3, SM2.7, CR1.7
- 800-161 SA-3
Roles
G.2.4 Security code review policy
Guidelines on which code should undergo a security-focused manual or automated review are communicated.
The policies for whether security-focused code review (a person looks directly at the code to find issues) and security-focused code analysis (tools are used to find issues in code, either in a fully automated way or in conjunction with a person) should be conducted based upon the characteristics/criticality of the software and its stage of development. Policies are established for code and AI models developed in-house and for third-party code and AI models.
Assessment questions
- What kind of guidelines are set in place for which code and models should be manually or automatically reviewed from a security perspective?
- How are these guidelines communicated and enforced?
Standard mappings
- EO 4e(iv)
- SSDF PW.7.1
- SSDF-AI PW.7.1
- BSIMM CR1.4, CR1.5
- 800-161 SA-11
- SELF-ATTESTATION 2, 4
G.2.5 Asset inventory
Hardware and software assets are inventoried to enable incident response; system analysis; traceability for critical components; and reliable identification when assets need to be changed or decommissioned.
Maintain a system component inventory, including hardware, software licenses, software versions, direct and transitive component owners, containers, machine names, and network addresses. Maintain an operations software inventory, including a map of source code; open source incorporated during the build and dynamic production; software deployments and related containerization, orchestration, and deployment automation code with respective owners. Unique identifiers for the inventoried assets should be established. Suppliers should also produce an asset inventory, for example through generating SBOMs. Particular attention should be placed when a product or system is retired.
Assessment questions
- How is an asset inventory automatically or manually generated and maintained?
- How do you integrate vulnerability management with asset inventory management, for example through SBOMs or software composition analysis?
- What process is used for the asset inventory to be updated when a product or system goes to end-of-life?
Standard mappings
- BSIMM CMVM2.3, SM3.1
- 800-161 CM-8, IA-4, PM-5
- OWASP-SCVS 1
- S2C2F INV-1
- CNCF-SSC M-V Require SBOMs and VEX statements from third-party suppliers, M-V Track dependencies between open source components
ATT&CK techniques
G.2.6 Protection of information at rest
Protect the confidentiality and integrity of information at rest.
Data protection at rest aims to secure the confidentiality and integrity of data stored on any storage device or network. Mechanisms to achieve confidentiality and integrity protections include using encryption and file share scanning. Provisions for protecting information at rest should be included in agreements with suppliers, developers, system integrators, external system providers, and other service providers.
Assessment questions
- What provisions are made for the protection of information at rest included in agreements with suppliers, developers, system integrators, and external system providers?
- What policies are set in place for the use of cryptography in the organization’s security policy?
Standard mappings
- 800-161 SC-28
G.3 Manage suppliers
5
G.3.1 Security-related contract terms
Component, system, AI model, and service acquisition policies include the inclusion of adherence to security policies, security requirements, and secure SDLC practices that are compatible with compliance requirements.
Compliance requirements, security requirements, and secure SDLC practices are included in vendor contracts with specified means of adherence enforcement. Examples include supplying an SBOM, VEX, self-attestation of security practices and provenance information; having a vulnerability disclosure program and incident response plan; and a security training program. The vendors include component, cloud, AI model, middleware providers, container and orchestration providers, and contractors.
Assessment questions
- What requirements language is included in system and services acquisition policies and contracts related to adherence to security policies, security requirements, and secure SDLC practices compatible with compliance requirements?
- How Do you obtain SBOMs, provenance data, and attestation of adhering to security practices from your suppliers?
- How is adherence to contract terms verified?
- How do you track the provenance of training, testing, fine-tuning, and aligning data used for AI models?
Standard mappings
- EO 4e(vi)
- SSDF PO.1.3
- SSDF-AI PO.1.3, PW.3.1, PW.3.2, PW.3.3
- SLSA Verifying artifacts
- OWASP-SCVS 1.5
- S2C2F ING-1
- CNCF-SSC M-V Require SBOMs and VEX statements from third-party suppliers
- BSIMM CP2.4, CP3.2, SR2.5, SR3.2
- 800-161 SA-1, SA-4, SI-3, SA-9, SR-4, SR-5, SR-6
- SELF-ATTESTATION 3
ATT&CK techniques
G.3.2 Separation of duties
Reduce the potential for abuse of authorized privileges and the chance of collusion when acquiring components, systems, and services.
Ensure that appropriate separation of duties is established for decisions that require the acquisition and administration of information systems and the acquisition of components entering the supply chain. Separation of duties can be used to deny contracted developers the privilege to promote code they wrote from development to the production environment. Separation of duties can prevent collusion, for example, by ensuring personnel administering access control functions do not also administer acquisition.
Assessment questions
- How is separation of duties established for decisions that require the acquisition of information systems and supply chain components, such as components entering the enterprise's supply chain or contracted developers promoting code from development to production?
Standard mappings
- 800-161 AC-5
G.3.3 Information disclosure
Contract language requires that a vendor monitors for information disclosure and notifies the enterprise of information disclosure.
Unauthorized disclosure of information is a form of data leakage. Monitoring should be in place for contractor systems to detect the unauthorized disclosure of any data, and contract language should include a requirement that vendors notify of unauthorized disclosure of information.
Assessment questions
- What kind of contract language is in place to stipulate that contractor systems conduct monitoring to detect unauthorized disclosure of any data?
- What kind of contract language is in place to require that vendors notify of unauthorized disclosure?
Standard mappings
- 800-161 AU-13
Roles
G.3.4 Session audits
Identify security risks in the supply chain.
Include contract employees and prime contractors in session audits to identify security risks in the supply chain. Session audits can include monitoring keystrokes, tracking websites visited, and recording information or file transfers and may involve implementing specialized session capture technology. As such, the privacy risks of session audits should be considered, and session audits may only be activated under certain circumstances, e.g., the organization is suspicious of a specific individual.
Assessment questions
- Under what circumstances are contract employees included in audits to identify security risks in the supply chain?
Standard mappings
- 800-161 AU-14
Roles
G.3.5 Notification agreement
Timely notification of security threat and product end-of-life
Require suppliers to establish agreements and procedures for notification and monitoring capabilities, including notification of being the target of a supply chain threat. Timely notification of compromises and potential compromises in the supply chain is essential for an organization to initiate an incident response. Establish a minimum amount of time a vendor must declare that a product will be declared end-of-life and will no longer be supported and understand what end-of-life options exist (e.g. replace, upgrade, migrate to a new system, etc.).
Assessment questions
- What notification agreements and monitoring capabilities are established with your suppliers related to supply chain threats or incidents?
- How much notification does a vendor provide when a product goes end-of-life?
- What end-of-life options exist?
Standard mappings
- 800-161 SR-8
Roles
G.4 Training
3
G.4.1 Role-based training
Provide security training for all personnel involved in software development
Provide literacy and role-based training on software security and secure software supply chain. This training should include information about the firm's security culture, the secure software development lifecycle, containerization and security orchestration, common security mistakes, technology such as CI/CD, AI models, and DevSecOps, and recognizing insider threat. Require this training as part of onboarding and periodically.
Assessment questions
- Describe the training given to employees and to vendors related to software supply chain security?
- Describe your process for scheduling and monitoring team member training in secure software architecture, design, development, testing, and software supply chain management.
- How do you customize the training specific to team roles, development tools, and languages?
Standard mappings
- EO 4e(vi)
- SSDF PO.2.2
- SSDF-AI PO.2.2
- BSIMM T1.1, T1.7, T1.8, T2.5, T2.8, T2.9, T3.1, T3.2
- 800-161 AT-2, AT-3, SA-16
G.4.2 Contingency training
Provide training on procedures in the event of a security emergency.
Conduct contingency training to prepare for emergency response, backup operations, and post-disaster recovery to ensure the availability of critical information resources in emergencies. Critical suppliers should also be included in the training.
Assessment questions
- Describe your contingency training for preparing for emergency response, backup operations, and post-disaster recovery.
Standard mappings
- BSIMM T1.1
- 800-161 CP-3, IR-2
G.4.3 Gather attack trends
Stay current on attack trends.
Have a process for continuously learning about emerging attack trends and vulnerabilities. Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, including AI models, and investigate all credible reports. Use a subscription to a cyber threat intelligence feed, attend technical conferences, monitor attacker forums, and study trends within the enterprise. Make this information on attack trends actionable and useful for developers, testers, security operations, and others to identify vulnerabilities in existing products, perform improved threat modeling and security architecture, and evolve the SDLC.
Assessment questions
- How do you monitor new attack trends and vulnerabilities applicable to your software and AI models, such as by monitoring a cyberthreat intelligence feed and attacker forums, or attending conferences?
Standard mappings
- EO 4e(vi), 4e(vii)
- SSDF RV.1.1
- SSDF-AI RV.1.1
- BSIMM AM1.5, CMVM1.2
- 800-161 SI-4, SI-5, RA-5
- SELF-ATTESTATION 2
G.5 Assess and manage risk
4
G.5.1 Criticality analysis
Identify critical system components and functions by performing a criticality analysis.
Perform a criticality analysis of system components, functions, or services to assign cybersecurity supply chain risk management activities commensurate with the analysis based upon the likelihood and impact of an attack. Not all system components, functions, or services necessarily require significant protection. Items to consider in the analysis include system assets/data involved in the product, applicable laws, regulations, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies. The criticality analysis impacts the procedures contractually imposed on vendors.
Assessment questions
- What process do you have for performing criticality analysis as input to assessments of supply chain risk management activities?
Standard mappings
- BSIMM AA1.4
- 800-161 RA-9
G.5.2 Track security risks and decisions
Record and track the software’s security risk-based exceptions and mitigation plans.
Record when a design tradeoff, vulnerability decision/exception, or component choice has been made that incurs security risk and a mitigation plan to reduce that risk including with vendors. Periodically re-evaluate these exceptions and mitigation plans, potentially including a review board that can provide security guidance in design guidance, patterns, standards, features, and frameworks.
Assessment questions
- How are the responses to security risks and design decisions recorded, including how mitigations are to be achieved?
- How are approved exceptions to the security requirements periodically evaluated?
Standard mappings
- EO 4e(v)
- SSDF PW.1.2
- BSIMM SFD3.1, SM3.5
ATT&CK techniques
G.5.3 Security metrics
Provide the basis for the measurement of an effective plan for tracking and realizing software security objectives within an organization.
Identify and regularly review metrics to measure the effectiveness of the software security program, including establishing Key Performance Indicators (KPIs). The regular review can drive budgeting and resource allocations and measure performance against risk appetite and risk tolerance statements. Publish data/dashboards about the state of software security within the organization. Automate metrics collection via security telemetry, as possible, to gather measurements to enhance efficiency and objectivity.
Assessment questions
- What security metrics do you track to indicate how you are doing relative to developing secure software products and having an effective and efficient software security program (e.g., security outcomes, MTTR)?
- Are these metrics collected automatically or manually?
Standard mappings
- BSIMM SM2.1, SM3.3
Roles
G.5.4 Data-informed product decisions
Make security decisions on software release based upon criteria for checking the security of the software.
Implement processes and mechanisms, automated when possible, to gather and safeguard information in support of security decision-making at the product level. This information can be used to drive SDLC change at the product or organizational level and/or drive a security risk exception process.
Assessment questions
- How do you use information from your toolchain to informs security decision-making automatically?
- If not, is this information collected and reviewed manually?
Standard mappings
- EO 4e(iv), 4e(v)
- SSDF PO.4.2
- BSIMM SM1.4, SM1.7
- 800-161 SA-15
- SELF-ATTESTATION 4
Roles
Product P
P.1 Develop security requirements
2
P.1.1 Product security requirements
Identify and document security requirements for organization-developed software, including AI models
Identify and document security requirements for organization-developed software, including AI models, including risk-reducing software architecture and design choices, security patterns, and translating compliance constraints to requirements. Examples include using memory-safe languages and secure frameworks, isolation and sandboxing component strategies, code modularity, security features, secure-by-design components, application containers, and product features that aid in secure deployment, operation, and maintenance. Containers can be used as a strategy for tighter coupling of an application and its dependencies, immutability, and some isolation benefits. Maintain these requirements over time.
Assessment questions
- How are risk-reducing security architecture and design requirements for products considered and developed?
- Which of the following strategies are considered: the use of memory-safe languages, secure frameworks, isolation, acceptance testing, and sandboxing?
- How are completion and adherence tracked?
Standard mappings
- EO 4e(iv)
- SSDF PO.1.2
- SSDF-AI PO.1.2
- BSIMM CP1.1, CP1.2, CP1.3, CP2.1, SE2.5, SFD1.1, SFD2.1, SDF3.2, SR1.3
- 800-161 SA-8, SA-17
Roles
P.1.2 Software release integrity
Provide software acquirers assurance that the software they acquire is legitimate and has not been tampered with.
Use code protection mechanisms, such as the use of an established certificate authority for code signing, to enable the attestation of the provenance, integrity, and authorization of important code and AI models. Make software integrity verification information, such as cryptographic hashes for release files, available to software acquirers on a well-secured website.
Assessment questions
- What software integrity artifacts do you make available to software acquirers, such as cryptographic hashes of release files?
- What certificate authority do you use for code/commit signing?
- How often do you review code signing processes, such as certificate renewal and key rotation?
- How do you manage and protect your signing server, for example is it dedicated?
Standard mappings
- EO 4e(iii)
- SSDF PS.2.1
- SSDF-AI PS.2.1
- SLSA Distributing provenance, Source L3: Signed and auditable provenance
- BSIMM SE2.4
- OWASP-SCVS 4.12, 6
- OSSF-SCORECARD signed-release, licenses
- CNCF-SSC A-V Validate the Signatures Generated at Each Step, A-A Use TUF to manage signing of artifacts
- S2C2F REB-2
P.2 Build security in
6
P.2.1 Security design review
Decrease the number of design flaws and security vulnerabilities introduced during the architecture and design phases.
Enumerate possible threat vectors. Conduct threat modeling and attack surface analysis to identify weaknesses in the software architecture and design such that the system is resistant to attack. Identify missing security features and requirements. Identify unused components in the design. Address the identified security risks through re-design, or develop and track a mitigation plan for exceptions.
Assessment questions
- For all critical software components and external services that your team operates and owns, has a qualified person not involved in the design reviewed the design and conducted an attack surface analysis and threat model?
- What kind of approaches are you using to narrow attack vectors?
- What kind of tool or methodology (like STRIDE) do you use to structure your threat modeling?
- Do you perform analysis such that only required modules are included in the product and unused modules are uninstalled and removed, decreasing the attack surface?
- How are unused modules identified - such as 'debloating' a product for unused components and containers?
Standard mappings
- EO 4e(iv), 4e(v), 4e(ix)
- OWASP-SCVS 3.20, 3.21
- SSDF PW.1.1, PW.2.1
- SSDF-AI PW.1.1
- BSIMM AA1.1, AA1.2, AA2.1, AA3.1
- SELF-ATTESTATION 4
- 800-161 SA-17
ATT&CK techniques
P.2.2 Secure coding
Decrease the number of security vulnerabilities introduced during source code creation.
Follow secure coding standards and practices appropriate to the development languages, APIs, AI models, and environment. Examples include validating all inputs, encoding outputs, and avoiding unsafe functions. Use development environments and static analysis tools that support compliance with secure coding practices as source code is being implemented.
Assessment questions
- What kind of secure coding practices are used?
- How are these practices communicated to developers and enforced?
Standard mappings
- EO 4e(iv)
- SSDF PW.5.1
- SSDF-AI PW.5.1
- BSIMM SR3.3, CR1.4, CR3.5
- SELF-ATTESTATION 4
P.2.3 Secure-by-default implementation
Improve the security of software at the time of installation.
Reduce the likelihood of software deploying with weak security settings by defining secure deployment parameters so that the default settings are secure and do not weaken the security functions provided by the platform, AI models, network infrastructure, or services.
Assessment questions
- How do you determine whether the default installation settings for products, platform, models, network infrastructure, services defined to be secure by default?
Standard mappings
- EO 4e(iv)
- SSDF PW.9.1, PW.9.2
- SSDF-AI PW.9.1
- BSIMM SE1.4
- 800-161 SA-5
- SELF-ATTESTATION 4
P.2.4 Standard security features
Reduce introducing new vulnerabilities by reusing standardized and proven security features.
Build support for standardized rather than proprietary security features, such as using existing log management, identity management, access control, or vulnerability management systems. These reused components are more likely to have their security posture already checked.
Assessment questions
- Please tell me about your philosophy of whether it is better to use available security features or to 'roll your own,' for example, log management, identity management, access control, and vulnerability management?
- What factors determine whether you use in-house or standard features?
Standard mappings
- EO 4e(ix)
- SSDF PW.1.3
- BSIMM SFD1.1, SFD3.2
P.2.5 In-house components
Maintain components built in-house.
Well-secured in-house components and scripts are built following a secure SDLC process when third-party components cannot meet development needs. Similar to the processes for third-party components, in-house components should be kept in a repository, maintained, and regularly scanned for vulnerabilities, with new versions deployed through the organization as needed.
Assessment questions
- What processes are used to scan in-house components built using SDLC processes for vulnerabilities, and how is the process similar or different to what is done for third-party components?
- What causes a need for a new version?
- How are in-house components monitored to ensure they are regularly maintained?
Standard mappings
- EO 4e(ix)
- SSDF PW.4.2
- BSIMM SFD2.1
- CNCF-SSC M-A Scan software for vulnerabilities
P.2.6 Confirm Integrity of AI model data
Evaluate AI foundation model, training, and fine-tuning data for potential security impacts.
Inputs to AI model training, evaluation, and the outputs of AI models should be evaluated for security risks, e.g. bias and data poisoning.
Assessment questions
- What processes are used to evaluate AI models build or consumed in your SDLC, and how is the process similar or different to what is done for third-party components?
- How are AI models monitored to ensure they are regularly maintained?
- How do you track the provenance of your AI models and data?
Standard mappings
- SSDF-AI PW.3
Roles
P.3 Manage component and container choices
4
P.3.1 Component and container choice
Make informed third-party component and container choices.
Consider component characteristics, such as the use of secure SDLC practice, evidence of ongoing maintenance, and open vulnerabilities, as quality indicators of direct and transitive dependencies. OpenSSF Scorecard metrics may be used as an indication of the security posture of a component. Components with the least functionality reduce the attack surface. Have a deny-list that prevents malicious components from being consumed.
Assessment questions
- What kind of approval process do you have, if any, for third-party libraries and containers included in a product?
- What do you consider when selecting a third-party component or container?
- Is considering solutions with the least functionality to reduce the attack surface part of your component selection process?
- How would the approval process handle dependencies that are no longer receiving updates?
- How do the OpenSSF Scorecard metrics factor in to decisions you make about components?
- Are you concerned when a component contains binary artifacts that cannot be easily reviewed and more easily sneak in a vulnerability?
- Do you have a Deny List to prevent the choice of vulnerable and malicious components?
Standard mappings
- BSIMM SR1.5
- 800-161 CM-7, SI-3
- OSSF-SCORECARD binary-artifacts, contributors, maintained
- S2C2F ING-3
- CNCF-SSC M: Second and third-party risk management
P.3.2 Trusted repositories
Obtain candidate packages and containers from trusted ecosystems or rebuild.
Trusted public repositories may require signed packages and provide the means to verify the signatures; the packages and containers from these ecosystems should still be scanned. Organizations should host scanned repositories for high-assurance software and restrict build machines to only those sources.
Assessment questions
- Describe any guidelines you have for searching for candidate components in package managers trusted by your organization?
- How do you develop, publish, and maintain lists of container registries you trust?
Standard mappings
- OWASP-SCVS 1.2, 4.19
- S2C2F ING-1
- CNCF-SSC M-V: Define trusted package managers, repositories, and libraries
P.3.3 Require signed commits
Utilize legitimate components and software that has not been tampered with.
Using code that has been contributed with signed source code commits provides an integrity mechanism.
Assessment questions
- How do you require the software producers to sign code commits of the components and tools you bring into your product?
Standard mappings
- BSIMM SE2.4
- CNCF-SSC BP-SA: Sign every step in the build process, SC-V Require verification attestations / confirmation
ATT&CK techniques
P.3.4 Vetted third-party component and container repositories
Engineers can choose from organization-approved components
Components, binaries, containers, and AI models chosen from public ecosystems undergo a vetting process, including reviewing component meta-data and provenance data; secure composition analysis; binary composition analysis; and other security scanning. Rebuild software dependencies from source code when possible to remove additional software that may be contained in a compiled version. Establish repositories to host organization-approved components and containers.
Assessment questions
- Describe the vetting and scanning process you use when you choose components, containers, binaries and AI models from public ecosystems or from third-parties.
- How do you arrange for a local component repository in which binaries and source code of third-party components are stored?
- What are your policies for rebuilding components from source?
Standard mappings
- EO 4e(iii), 4e(vi), 4e(x)
- SSDF PW.4.1
- SSDF-AI PW.4.1
- BSIMM SFD2.1, SFD3.2, SR2.4, SR2.7
- SLSA Verifying artifacts, Build L1: Provenance exists
- 800-161 SI-3, SR-3, SR-4, SR-11
- OWASP-SCVS 5
- S2C2F SCA-1, SCA-4, SCA-5, ING-2, ING-4, ENF-2
- CNCF-SSC A-CE Use a container registry that supports OCI image-spec images, M-V: Verify third party artifacts and open source libraries; SM, M-V Build libraries from source code, M-A Run software composition analysis on ingested software
- SELF-ATTESTATION 2, 3
ATT&CK techniques
P.4 Discover vulnerabilities
5
P.4.1 Security code review
Detect security vulnerabilities introduced during architecture, design, and source code creation including those injected with malicious intent
Perform peer code review on in-house developed code, AI-generated code, and some third-party code based on the organization’s secure coding standards. Create and use review checklists that may be informed by 'Top N' vulnerability lists. While the manual review of another programmer before check-in is essential for finding vulnerabilities injected with malicious intent, supplementing code review with automated tools, such as static analysis tools, is beneficial. Record and triage discovered issues and recommended remediations in the development team’s workflow or issue-tracking system.
Assessment questions
- How does the team perform security-related code reviews?
- Describe the secure coding standards your teams use, if any.
- How do discovered vulnerabilities get recorded, tracked, and remediated?
Standard mappings
- EO 4e(iv), 4e(v)
- SSDF PW.7.2
- SSDF-AI PW.7.2
- SLSA Source L4: Two-party review
- BSIMM CR1.2, CR1.4, CR2.8, CR2.6, CR2.7, CR3.4, CR3.5
- OSSF-SCORECARD code-review
- CNCF-SSC C: Enforce independent 2-party review
- SELF-ATTESTATION 4
ATT&CK techniques
P.4.2 Automated security scanning tools
Choose tools to efficiently discover previously-undetected vulnerabilities
Specify which tools or tool types must or should be included in each toolchain to reduce human effort in discovering vulnerabilities and mitigating identified security risks and to improve the accuracy, reproducibility, usability, and comprehensiveness of security practices in the SDLC. Tools commonly include SAST, DAST, IAST, SCA, and secret detection tools. Specify how the toolchain components will be integrated, such as through the CI/CD pipeline. Follow recommended practices for tool selection/scanning, deploying, operating, and maintaining tools and toolchains.
Assessment questions
- What security tools are in your toolchain?
- SAST?
- DAST?
- IAST?
- How often is the scanning done for third-party components?
- Do you use a tool to detect secrets in code?
- What happens with the reported vulnerabilities?
- How do you scan your tools for vulnerabilities?
- How do you scan acquired AI models for security issues?
- How do you scan released AI models for security issues?
Standard mappings
- EO 4e(i)(F), 4e(ii), 4e(iii), 4e(v), 4e(vi)
- SSDF PO.3.1, PO.3.2
- SSDF-AI PO.3.1, PO.3.2
- BSIMM CR1.4, SE.3.9, ST1.4, ST2.5
- 800-161 SA-15
- OWASP-SCVS 5.1, 5.4
- OSSF-SCORECARD sast, fuzzing
- SELF-ATTESTATION 1f, 2, 3
P.4.3 Automated vulnerability detection
Detect vulnerabilities before deployment through the use of automated tools to reduce the window of opportunity for attackers.
Review, analyze, and/or test the software’s code, and the tools used to build it, including AI models, to identify or confirm the presence, remediation, and disclosure of previously undetected vulnerabilities. Tools commonly include SAST, DAST, IAST, SCA, and secret detection tools. Record and triage discovered issues and recommended remediations in the development team’s workflow or issue-tracking system.
Assessment questions
- How is code reviewed, analyzed, and tested to identify or confirm the presence, remediation, and disclosure of previously-undetected vulnerabilities such as through automated tools?
- How are the tools in the build and deploy pipelines reviewed, analyzed, and tested to identify or confirm the presence, remediation, and disclosure of previously-undetected vulnerabilities such as through automated tools?
Standard mappings
- EO 4e(iv), 4e(vi), 4e(viii)
- SSDF RV.1.2
- SSDF-AI RV.1.2
- BSIMM CMVM3.1
- 800-161 SA-11, RA-9, SI-7
- OWASP-SCVS 5.1, 5.2
- CNCF-SSC SC-A: Prevent committing secrets to source code repository, SC-A: Automate software security scanning, M-A: Scan software for vulnerabilities, M-A Run software composition analysis on ingested software, A-V Perform additional checks on the artifact
- SELF-ATTESTATION 3, 4
P.4.4 Executable security testing
Discover vulnerabilities only detected through executable testing
Executable testing, such as done by in-house testers or third-party penetration testers, is performed to find previously-undiscovered vulnerabilities. In-house testers should be guided by design review results, threat modeling, security requirements, and the security mechanisms in security features. Testing should include containers and AI models. Automate security tests as possible. Scope the testing, design the tests, perform the testing, and document the results, including recording and triaging all discovered issues and recommended remediations in the development team’s workflow or issue tracking system. Test the build process and scripts.
Assessment questions
- How are security features tested?
- How are test cases developed to test the security of an application?
- How is security testing factored into a product's test suite?
- How is executable code testing, such as in-house or external penetration testing, used to find vulnerabilities not found by previous reviews, analysis, and testing?
- How do you conduct executable testing on containers?
- How do you test your build process, scripts, GitHub actions?
Standard mappings
- EO 4e(iv), 4e(v)
- SSDF PW.8.1, PW.8.2
- SSDF-AI PW.8.1, PW.8.2
- BSIMM ST1.1, ST1.3, ST1.4, ST2.4, ST2.5, ST2.6, ST3.3, ST3.4, ST3.5, ST3.6, PT1.1, PT1.2, PT1.3, PT2.3, PT3.1, CMVM3.4
- 800-161 SA-11
- OSSF-SCORECARD ci-tests
- SELF-ATTESTATION 2, 4
Roles
P.4.5 Regular third-party compliance
Identify increased security risk of third-party and open-source components
Regularly check that third-party software components, including AI models, comply with the contractual requirements, such as following a secure SDLC, and fix detected vulnerabilities. Regularly scan components and containers to monitor for vulnerabilities and for evidence that artifacts are being maintained and have not been abandoned or deprecated.
Assessment questions
- How do you verify that third-party software components continue to comply with the requirements defined by the organization, such as through using a secure SDLC and the delivery of attestation of security practices?
- How do you check that components are being maintained and are not at end-of-life or have been abandoned?
- How are known critical vulnerabilities in third-party and open-source components and containers mitigated?
Standard mappings
- EO 4e(iii), 4e(iv), 4e(vi), 4e(x)
- SSDF PW.4.4
- SSDF-AI PW.4.4
- 800-161 SA-4, SA-9, SA-11, SA-15, SR-3
- OWASP-SCVS 5, 5.8
- S2C2F SCA-1, SCA-3
- SELF-ATTESTATION 2, 3, 4
- CNCF-SSC BP-SA Deploy monitoring tools to detect malicious behavior, D-A Continuous vulnerability scanning
P.5 Manage vulnerable components and containers
2
P.5.1 SBOM consumption
Utilize SBOM information to react to security incidents and to identify which components need to be updated or patched.
Obtain or generate an SBOM for a product that provides a clear and direct link to the dependencies and their versions used within a product. Ideally, the SBOM will provide signed metadata from the build process. Tools can automate analysis and obtain desired information from the SBOM, such as aligning with vulnerability data to identify vulnerabilities within the exact package contents.
Assessment questions
- How are SBOMs checked for information about pending security vulnerabilities?
- How do you consume the SBOMs for your components?
- Describe your experiences with being aided by information provided by the SBOM?
- How do you feel about the assistance provided by tools to help you consume an SBOM?
- If not now, do you have plans to consume SBOMs in the future?
- How do you consider and trust the VEX information in the SBOM?
- What expectations do you put on the component producers for the vulnerabilities identified in the SBOM?
Standard mappings
- 800-161 SR-4
- OWASP-SCVS 5.4
- CNCF-SSC M-V: Require SBOMs and VEX statements from third-party suppliers, M-V Track dependencies between open source components
ATT&CK techniques
P.5.2 Dependency update
Update vulnerable dependency when a fixed version is available
SCA tools, SBOM tools, and ecosystem tools (such as Dependabot) inform a product of vulnerabilities and provide an automated pull request for new versions of direct and transitive dependencies discovered vulnerable. Organizations need a process/strategy for updating dependencies - which may be manual or automated. Specify the software assets that require automated updates, defined from criticality/risk-based analysis. Rebuild, do not patch, containers with vulnerabilities.
Assessment questions
- What is your strategy for updating dependencies based on SCA, SBOM, or automated pull requests?
- What is your strategy for updating dependencies, such as through a tool such as Dependabot that automates PR?
- How does the project use tools to help update its dependencies e.g. Dependabot, RenovateBot?
- Describe the risk/criticality prioritiziation scheme used when updating assets. How are the software assets that require automated updates defined from a criticality/risk-based perspective?
- How are containers updated when a vulnerability is detected?
Standard mappings
- 800-161 SI-2
- OWASP-SCVS 5.8
- SSDF RV.1.1
- OSSF-SCORECARD dependency-update-tool
- S2C2F UPD-1, UPD-2, UPD-3
Environment E
E.1 Safeguard artifact integrity
6
E.1.1 Safely store release artifacts
Preserve release artifacts to help in the identification and analysis of vulnerabilities discovered after release.
Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data, attestations, metadata) to be retained for each software release.
Assessment questions
- What files and supporting data (like integrity validation, provenance, configuration files, and metadata) do you securely archive and retain for each software release?
Standard mappings
- EO 4e(iii), 4e(vi), 4e(x)
- SSDF PS.3.1
- SSDF-AI PS.3.1
- SLSA Source L3: Signed and auditable provenance
- OWASP-SCVS 6.3
- CNCF-SSC SC-V Authenticate and monitor repository activity
E.1.2 Version control
Prevent unauthorized changes to artifacts, both inadvertent and intentional.
Store project artifacts, including but not limited to source code, executable code, infrastructure as code, AI models, and configuration-as-code, in a repository with restricted access using the principle of least privilege based on the nature of the artifact. Use version control to track and store all changes to this code with accountability to an authenticated individual account with access granted to personnel, tools, and services. As appropriate, sign or encrypt artifacts. Indefinitely retain change history.
Assessment questions
- Describe how code and other important project artifacts are stored, e.g., with version control with access granted to strongly-authenticated personnel using the principle of least privilege.
Standard mappings
- EO 4e(i)C, 4e(iii), 4e(iv)
- SSDF PS.1.1
- SSDF-AI PS.1.1, PS.1.2, PS.1.3
- 800-161 SA-8, SA-10
- CNCF-SSC SC-V Authenticate and monitor repository activity
- OWASP-SCVS 4.10
- SLSA Source L1: Version controlled
E.1.3 Multi-factor authentication (MFA)
Decrease the chances an account will be compromised.
Enforce multi-factor authentication (MFA) at the source code repository level by requiring a soft or physical token in addition to traditional passwords/credentials that are more likely to be compromised using techniques such as brute force guessing.
Assessment questions
- How is MFA mandated and enforced at the source code repository level?
- Describe the tokens that are used, e.g. are soft or physical tokens used?
- How is MFA enforced for endpoints?
Standard mappings
- OWASP-SCVS 4.5
- CNCF-SSC SC-SA: Enforce MFA for accessing source code repositories
Roles
E.1.4 Developer SSH key
Decrease the chances developer account will be compromised.
Use SSH keys or SSH certificates for developers and agents in CI/CD pipelines to access source code repositories from their development tools rather than traditional passwords/credentials that are more likely to be compromised. Passphrases should be used to protect SSH keys.
Assessment questions
- How do you avoid using passwords, e.g., through the use of SSH keys, SSH certificates, or short-term rotated Access Tokens?
Standard mappings
- CNCF-SSC SC-SA: Use SSH keys to provide developers access to upstream source code repositories
ATT&CK techniques
E.1.5 Branch protection
Provide a formal approval process for code changes to enforce adherence to software development processes and policies before code is introduced into a CI/CD system.
Branch protection settings to enforce security policies, such as requiring reviews, passing checks, preventing overwriting of history, and signed commits before code is accepted into the main branch. Branch protection can prevent forced pushings, overwriting history, and obfuscation of code changes. In high-risk, high-assurance environments, attribution of code changes, commit signing, and full attestation can be used with branch protection to prevent and detect complex attacks.
Assessment questions
- Describe your use of branch protection settings to enforce security policies, such as requiring reviews, passing checks, preventing overwriting of history, and signed commits before code is accepted into the main branch?
- In high assurance, high risk environments, is commit signing with full-attestation required?
Standard mappings
- OSSF-SCORECARD branch-protection
- OWASP-SCVS 4.17
- SLSA Source L2: Controls
- CNCF-SSC SC-V Declare protected repository namespaces, SC-V Require verification attestations / confirmation, SC-CE Establish and adhere to contribution policies
ATT&CK techniques
E.1.6 Decommission assets
Prevent security attacks through live end-of-life systems and products
Live but abandoned systems may not get new security patches or be monitored for malicious activity, even though they may be vulnerable to new security threats and can be an attack vector. When a product or system has been declared end-of-life, decommission associated accounts, machines, data, keys, and passwords.
Assessment questions
- What decommissioning procedures are in place when a live product or system goes to end-of-life?
Standard mappings
- OWASP-SCVS 5.8
- 800-161 SA-22
E.2 Safeguard build integrity
8
E.2.1 Release policy verification
Ensure the products, materials, and processes used during the build pipeline adhere to the established product and organizational release policy
A release policy should be maintained as a policy template and outline the required workflow while the software is developed, built, tested, and packaged to ensure the integrity, authentication, and auditability of a software product from initiation to end-user installation. A framework, such as in-toto, can produce meta-data during the build pipeline to enable attestation to the steps in the desired workflow. The meta-data can be analyzed to ascertain whether the steps in the workflow have occurred and to produce cryptographic guarantees by hashing and signing the inputs and outputs of steps in the pipeline.
Assessment questions
- How do you specify a templated build policy that specifies the required build workflow to ensure the integrity, authentication, and auditability?
- How do you verify the build policy in a cryptographically provable way, such as with in-toto?
Standard mappings
- SLSA Build L2: Hosted build platform
- CNCF-SSC BP-V Enforcing policy, SC-V Require verification attestations / confirmation, A-V Policy
E.2.2 Verify dependencies and environment
Ensure the build environment’s sources and dependencies come from a secure, trusted source of truth
Analyze the integrity of build tools, components, and containers before bringing them into the pipeline. Validate the point of origin/provenance, checksums, and signatures in the downloading and ingesting processes. Request SBOM, provenance, and self-attestation to aid in achieving this goal.
Assessment questions
- How do you track packages back to their repositories?
- How do you verify the integrity (i.e. digital signature or hash match) and the provenance data of each component and container?
- How do you validate that the build environment's sources and dependencies come from a secure, trusted source of truth?
- What is your dependency version constraint strategy, e.g. how do you manage pinning and floating versions of your dependencies?
- How do you validate that the deployment environment's sources and dependencies come from a secure, trusted source of truth?
Standard mappings
- OSSF-SCORECARD pinned-dependencies
- SLSA Verifying artifacts
- OWASP-SCVS 1.10, 4.13, 4.19
- S2C2F AUD-1, AUD-3, AUD-4
- CNCF-SSC M-V: Verify third-party artifacts and open source artifacts, BP-V: Validate environments and dependencies before usage, D-V Admission controller/deployment gate
E.2.3 Defensive compilation and build
Reduce vulnerabilities during compilation and build.
Determine which compiler, interpreter, AI training, and build tool features should be used to reduce vulnerabilities, such as producing compiler warnings for vulnerable code that are treated as errors; application of obfuscation techniques; approved configurations being used; verification of sources and manifests of dependencies; and approved tools configurations are available as configuration-as-code.
Assessment questions
- How do you use compiler, interpreter, and build tool features to detect vulnerabilities?
- Describe your system for preventing use of a vulnerable and/or malicious component in the build, e.g. a Deny List.
Standard mappings
- EO 4e(iv)
- SSDF PW.6.1
- SSDF-AI PW.6.1
- SLSA Verifying build platforms
- OWASP-SCVS 3
- S2C2F REB-1
- SELF-ATTESTATION 3
E.2.4 CI/CD hosting and automation
Through automated builds, reduce human error and malicious actions and artifacts that cause the output of the build process to contain security vulnerabilities.
All CI/CD pipeline build steps should be automated with automation standardized across the enterprise via clear templated build pipelines that meet organizational standards. This automation should be treated as 'pipeline as code' with modifications being reviewed and should be immutable. The build runs on a hosted build platform that generates and signs the provenance.
Assessment questions
- How do you ensure reproducibility of your build processes, e.g. through defined build scripts, with the only manual step being to invoke the script?
- Do you store the build definition executed by the build service in a version control system fetched through a trusted channel with a trustworthy provenance chain?
- How do you ensure the build environment is reproducible, e.g.Does the build run on a hosted build platform?
- How are the build steps, sources, and dependencies declared up front with immutable references/use immutable artifacts stored in a local repository manager?
- How are infrastructure, build scripts, and GitHub Actions handled 'as code', such as with code review, scanning, testing, and version control?
- How are configuration changes reviewed?
- How are CI/CD pipelines standardized across the enterprise?
Standard mappings
- EO 4e(iv)
- SSDF PW.6.2
- SSDF-AI PW.6.2
- BSIMM SE2.4, SE3.2
- SLSA Build L2: Hosted build platform, Source L3: Signed and auditable provenance
- OWASP-SCVS 2, 3
- OSSF-SCORECARD dangerous-workflow, token-permissions, pinned-dependencies
- CNCF-SSC BP-A: Build and related CI/CD should be automated, BP-A: Standardize pipeline across projects, BP-A: Build workers should be single-use, BP-CE: Ensure software factory had minimal network connectivity, BP-CE: Pass in build worker environment and commands, BP-SA: Only allow pipeline modifications through 'pipeline as code'
- SELF-ATTESTATION 4
ATT&CK techniques
E.2.5 Secured orchestration platform
Ensure each deployed workload meets predetermined security requirements.
The build pipeline should be a series of hardened build steps implemented through a hardened container image stored within a secured repository and deployed through a hardened orchestration platform, such as Kubernetes. Orchestration processes can take advantage of built-in and added-on security features, such as checking for secrets and rollbacks to ensure that each deployed workload meets predetermined security requirements.
Assessment questions
- How are containers used throughout the build process?
- Describe your orchestration layer, e.g. Kubernetes, if present.
Standard mappings
- BSIMM SE2.7
- SLSA Build L3: Hardened builds
- CNCF-SSC BP-A: Provision a secured orchestration platform
E.2.6 Reproducible builds
Provide a mechanism to confirm that no malicious backdoor injections have taken place during the build process.
Follow recommended security practices to deploy, operate, and maintain tools and toolchains, including the reproducible build steps whereby identical input artifacts are rebuilt from source in a trusted build environment, non-determinism is eliminated, and the results can be cryptographically attested to be the same output in a bit-for-bit comparison.
Assessment questions
- Describe your stance on reproducible builds, e.g. do you practice reproducible builds on different protected environments and compare bit-for-bit results?
Standard mappings
- S2C2F REB-1
- CNCF-SSC BP-V Validate build artifacts through verifiably reproducible builds, BP-V Recommendations for Reproducible Builds
ATT&CK techniques
Roles
E.2.7 Build output
Through protected build environments, reduce human error and malicious actions and artifacts that cause the output of the build process to contain security vulnerabilities.
Write the output from the build process to separate storage from the inputs. A process separate from the build process should upload the artifact to the appropriate deployable repository.
Assessment questions
- How does the project store the build artifacts?
- How does the project build and publish official packages?
Standard mappings
- OSSF-SCORECARD packaging
- CNCF-SSC BP-CE: Write output to a separate secured storage repo
E.2.8 Hardened and isolated builds
Protect the integrity of build output
Builds should run in an ephemeral and hermetic (isolated and sealed) environment with no parameters or network connectivity except to the hardened local repository of source code and dependencies and code signing infrastructure.
Assessment questions
- How do you ensure that the build service runs in an ephemeral environment, such as a container or VM, provisioned solely for the build?
- How do you ensure that the build service runs in an isolated environment free of influence from other build instances?
- How can the build output be affected by user parameters other than the build entry point?
- Is the build run with no network access (i.e., hermetic)?
Standard mappings
- SSDF PW.6.2
- OWASP-SCVS 3
- SLSA Build L3: Hardened builds
- CNCF-SSC Build L3: Hardened builds, BP-A Build Workers Should be Single Use, BP-CE Ensure Build Pipeline has minimal network connectivit, BP-CE Segregate the Duties of Each Build Worker, BP-CE Pass in Build Worker Environment and Commands
E.3 Secure software development environment
10
E.3.1 Authentication
Enable authorization, traceability, and non-repudiation
Authenticate employees and contractors to enable access control, traceability, non-repudiation, chain-of-custody, and provenance for systems, software, and services.
Assessment questions
- How are employees and contractors authenticated to enable access control, traceability, non-repudiation, chain of custody, and provenance for systems, software, and services?
- Where do you store access credentials (e.g., hashes for passwords) and secrets in a secured (e.g., encrypted) location, such as a secure vault?
Standard mappings
- 800-161 IA-5, IA-9
E.3.2 Environmental separation
Separate and protect each environment involved in software development (i.e., development, build, test, deployment, model training)
Using network segmentation and access control to separate and protect each environment (e.g., endpoints, development, build, test, deployment, model training) involved in software development to protect from internal and external threats. Remote access to the build environment should be rare, logged, and require multi-party approval. Log and monitor access, particularly privileged access. Configure the environment's hosting infrastructure following a zero-trust architecture.
Assessment questions
- How are environments involved in software development (e.g., endpoints, development, build, test, model training, deployment) separated and protected from physical and remote access to the build environment?
- How is access logged?
- How are approvals arranged for access to the build environment?
- How are the build environment workstations held to a security standard, e.g. up-to-date patches, anti-virus definitions, etc?
Standard mappings
- EO 4e(i)(A), 4e(i)(B), 4e(i)(C), 4e(i)(D), 4e(i)(E), 4e(i)(F), 4e(ii), 4e(iii), 4e(v), 4e(vi)
- SSDF PO.5.1, PO.5.2
- SSDF-AI PO.5.1
- BSIMM SE3.10
- 800-161 SA-8, SA-15
- CNCF-SSC D-V Air-gapped deployment
- SELF-ATTESTATION 1a, 1b, 1c, 1d, 1e, 1f, 2, 3
Roles
E.3.3 Role-based access control
Controlling access to resources where permitted actions on resources are identified with roles rather than with individual subject identities; provide traceability between actors and actions
Define a set of roles and accounts with an associated access control/authorization level considering remote access requirements, the period for which access is needed, and careful vetting of contractor personnel. These roles can be used for access control to ensure proper traceability of actions and actors. A process should be implemented to manage mission-critical systems' temporary or emergency access. Role-based access is enforced by physical and logical access enforcement mechanisms.
Assessment questions
- How are authorization levels for accounts associated with roles and the associated level of access control, including remote access, proper vetting of contractors, and that authorization does not exceed the period of performance?
- How are access control violations handled?
Standard mappings
- 800-161 AC-2, AC-3, AC-6, AC-17, IA-2
- CNCF-SSC A-CE Limit which artifacts any given party is authorized to certify, SC-CE Establish and adhere to contribution policies, SC-CE Define roles aligned to functional responsibilities, BP-SA Define user roles
ATT&CK techniques
- T1003
- T1021
- T1036
- T1047
- T1053
- T1055
- T1059
- T1068
- T1072
- T1078
- T1080
- T1098
- T1110
- T1112
- T1134
- T1136
- T1185
- T1190
- T1199
- T1210
- T1213
- T1218
- T1222
- T1484
- T1486
- T1489
- T1490
- T1496
- T1505
- T1525
- T1528
- T1530
- T1537
- T1538
- T1546
- T1548
- T1550
- T1552
- T1553
- T1555
- T1556
- T1558
- T1563
- T1565
- T1569
- T1578
- T1585
- T1586
- T1606
- T1609
- T1610
- T1621
- T1649
- T1651
E.3.4 Information flow enforcement
Limit the information flow across trust boundaries to participants in the supply chain
Specify how information flow across trust boundaries is enforced to ensure only the required information is communicated to participants in the supply chain, including but not limited to suppliers, developers, system integrators, and external system providers. Requirements for transmission confidentiality and integrity are integrated into agreements with suppliers. The degree of protection should be based on the sensitivity of the information. Security mechanisms such as authentication, authorization, and encryption can be used to achieve enterprise confidentiality and integrity requirements.
Assessment questions
- How is information flow enforced to ensure only the required information is communicated across trust boundaries to participants in the supply chain through mechanisms that ensure transmission confidentiality and integrity?
- What kind of requirements for transmission confidentiality and integrity are integrated into agreements with suppliers?
Standard mappings
- 800-161 AC-4, SC-8
E.3.5 Baseline configuration
Provide the starting point for tracking changes to components, code, and settings throughout the SDLC
Establish a baseline configuration of the information system and the development environment, including documenting, formally reviewing, and securing the agreement of stakeholders. The baseline provides a starting point for tracking changes to components, code, and settings for traceability and provenance.
Assessment questions
- How is a baseline configuration of the information system and development environment initialized to provide a starting point for tracking changes to components, code, and/or settings for traceability and provenance?
- Who sets the baseline?
Standard mappings
- 800-161 CM-2
E.3.6 Monitor changes to configuration settings
Prevent the tapering of information systems and networks through the monitoring of changes to configuration settings.
Monitor and audit configuration settings and change controls within the information systems and networks throughout the SDLC. Changes should be tested and approved before being implemented. Configuration settings should be monitored so designated employees can be alerted when a change has occurred.
Assessment questions
- What kind of monitoring and auditing of changes to configuration settings is in place?
- What designated employees are alerted when an unauthorized change occurs?
Standard mappings
- 800-161 CM-3, CM-6
ATT&CK techniques
E.3.7 Boundary protection
Monitors and controls communications at the external boundary of the system and at key internal boundaries within the system.
The enterprise should consider the trust boundaries and provide separation and isolation of development, test, and security assessment tools and external networks or information systems. The connections should only be through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.
Assessment questions
- How are development, test, and security assessment tools and operational environments separated and isolated from external networks or information systems and each other, as appropriate considering trust boundaries?
- How are trust boundaries considered, and how is the separation/isolation implemented?
- How is malicious behavior detection implemented and managed?
Standard mappings
- 800-161 SC-7
- CNCF-SSC BP-SA Deploy monitoring tools to detect malicious behavior
ATT&CK techniques
Roles
E.3.8 Key rotation
Limit the impact if a key is compromised.
Have a key rotation policy to ensure that compromised keys will cease to be usable after a certain period. Replace and revoke a private key immediately if it is known to have been compromised to shut off access.
Assessment questions
- What is your key rotation policy?
Standard mappings
- CNCF-SSC A-CE Build in a system for rotating and revoking private keys, SC-SA: Have a key rotation policy
Roles
E.3.9 Ephemeral credentials
Reduce the number of potential entry points for a hacker, as well as the attack surface.
As an alternative to passwords, ephemeral credentials are randomly generated, short-lived access credentials that exist only for one session to authenticate and authorize privileged connections. These credentials are automatically issued as needed, so users do not have to input credentials when connecting and enable fine-grained permissions and automation of provisioning access tokens.
Assessment questions
- Describe your approach to access management for machines and services such as CI/CD pipeline agents, e.g. do you use short-lived tokens.
- Who uses these tokens and for what types of systems?
Standard mappings
- CNCF-SSC SC-SA: Use short-lived/ephemeral credentials, BP-SA Use Short-Lived Workload Certificates
E.3.10 Establish a root of trust
Provide the foundation for secure operations of a computing system
Roots of trust (RoT) are highly-reliable hardware, firmware, and software components that perform specific, critical security functions, such as storing the keys used for cryptographic functions and enabling a secure boot process. Many RoT are implemented in hardware so that malware cannot tamper with the functions they provide. The RoT is established from an offline source.
Assessment questions
- Describe your root of trust for performing specific, critical security functions such as storing keys for cryptographic functions or enabling secure boot. How are these implemented?
Standard mappings
- CNCF-SSC BP-SA: Follow best practices for establishing a root of trust from an offline source
Roles
Deployment D
D.1 Respond to/disclose vulnerabilities
5
D.1.1 Vulnerability analysis
Plan the resolution of discovered vulnerabilities
Enter discovered vulnerabilities into a defect management system. Analyze each vulnerability to gather sufficient information to plan its remediation. Plan a risk response and prioritization, such as by estimating the probability of exploitation and the impact if it is exploited.
Assessment questions
- How are discovered vulnerabilities recorded and triaged?
- How are the vulnerabilities prioritized for remediation?
- What mechanisms are used for prioritization, e.g. is a severity rating, such as CVSS, used to aid prioritization?
- Is the access control to vulnerability information more restrictive than plain bug tracker defects?
Standard mappings
- EO 4e(iv), 4e(viii)
- SSDF RV.2.1
- SSDF-AI RV.2.1
- S2C2F SCA-5
- BSIMM CMVM1.3
- 800-161 SA-15
D.1.2 Risk-based vulnerability remediation
Remediate vulnerabilities based upon a risk-based prioritization
Make risk-based decisions on whether to remediate a vulnerability or if the risk will be addressed another way (e.g. acceptance, temporary remediation, deferred remediation). Prioritize actions that will be taken. Deliver remediations via an automated and trusted delivery mechanism.
Assessment questions
- Tell me about your process for making decisions on which vulnerabilities should be remediated?
- What is your process for responding to reported incidents quickly?
- Do you have a policy that high-priority vulnerabilities can prevent the shipment of the product?
Standard mappings
- EO 4e(iv), 4e(v), 4e(viii)
- SSDF RV.2.2
- SSDF-AI RV.2.2
- 800-161 SA-5, SA-11
- OSSF-SCORECARD vulnerabilities
D.1.3 Vulnerability disclosure
Aid organizations in responding to vulnerabilities to reduce the window of opportunity for attackers
Have a policy that invokes vulnerability disclosure and remediation, and organizational response. Implement the roles, responsibilities, and processes needed to support that policy, including a Product Security Incident Response Team (PSIRT) to handle responses to vulnerability reports and incidents. The disclosure program will require insight from internal stakeholders, such as legal, marketing, and public relations.
Assessment questions
- What is your process for addressing vulnerability disclosure and remediation with roles, responsibilities, and processes in place?
- How do you develop and release security advisories to your software acquirers?
- How do you publish a security policy (e.g. via a security.md file) to inform users about a vulnerability and how to report it?
- How do users know how to report vulnerabilities?
- Who handles PSIRT?
Standard mappings
- EO 4e(viii)
- SSDF RV.1.3
- SSDF-AI RV.1.3
- BSIMM CMVM1.1, CMVM1.4, CMVM2.4
- 800-161 SA-15
- S2C2F INV-2
- OSSF-SCORECARD security-policy
Roles
D.1.4 Vulnerability eradication
Proactively eradicate classes of vulnerabilities.
Review the software for similar vulnerabilities to eradicate a class of vulnerabilities, not just the instance originally discovered. Proactively fix a class of vulnerabilities rather than waiting for the discovery of each vulnerability through automation, testing, or an external incident. Automation and custom rules in vulnerability discovery tools or compilers can be used. Patterns of remediation efforts should provide feedback into the secure SDLC.
Assessment questions
- Describe the team's process of proactively eradicating or reducing a whole class of vulnerabilities based upon previously-identified vulnerabilities or incidents?
- How are these patterns folded back into the SDLC?
Standard mappings
- EO 4e(iv), 4e(viii)
- SSDF RV.3.3
- SSDF-AI RV.3.3
- BSIMM CR3.3, CMVM3.1
- 800-161 SI-2
D.1.6 Root cause analysis
Reduce the frequency of vulnerabilities in the future
Analyze vulnerabilities discovered throughout the process and in production to determine their root cause for being injected and not discovered earlier before production. Incident response feedback should be fed back to developers and be considered when evolving the SDLC. Record lessons learned. Identify patterns, such as security controls in the SDLC needing to be followed. Discuss and disseminate these patterns to developers. Guide process correction if the current process is not being followed.
Assessment questions
- How do you analyze identified vulnerabilities to determine their root cause, including how the vulnerability was injected and, perhaps, how it escaped vulnerability detection efforts and made it into production?
- How do you communicate trends to developers? How can trends identified in root cause be factored into your SDLC process?
Standard mappings
- EO 4e(ix)
- SSDF RV.3.1, RV.3.2, RV.3.4
- SSDF-AI RV.3.1
- BSIMM CP3.3, CMVM3.2
ATT&CK techniques
D.2 Monitor intrusions/violations
2
D.2.1 System monitoring
Detect runtime product anomalies
Continuously monitor the running system to gather information for risk decisions, criticality analysis, vulnerability and threat analysis, incident response, policy non-compliance, and insider threat detection, including boundary protection, supply chain components, and supply chain information flow.
Assessment questions
- How are running systems continuously monitored to gather information for risk decisions, criticality analysis, vulnerability and threat analysis, incident response, and insider threat, including boundary protections of supply chain components and supply chain information flow?
- What is the process when an intrusion or violation is detected? Is there a QoS target?
Standard mappings
- EO 4e(vii)
- SSDF-AI PO.5.3
- 800-161 CA-7
- CNCF-SSC BP-SA Deploy monitoring tools to detect malicious behavior, D-A Continuous vulnerability scanning
ATT&CK techniques
- T1003
- T1012
- T1016
- T1018
- T1021
- T1027
- T1036
- T1041
- T1049
- T1053
- T1055
- T1057
- T1059
- T1068
- T1070
- T1071
- T1078
- T1080
- T1082
- T1083
- T1105
- T1119
- T1129
- T1132
- T1140
- T1176
- T1189
- T1190
- T1195
- T1203
- T1210
- T1211
- T1212
- T1213
- T1218
- T1482
- T1484
- T1486
- T1490
- T1496
- T1497
- T1499
- T1518
- T1528
- T1543
- T1546
- T1547
- T1548
- T1550
- T1552
- T1555
- T1556
- T1558
- T1560
- T1562
- T1568
- T1573
- T1574
- T1586
- T1595
- T1606
- T1622
- T1665
Roles
D.2.2 Build process monitoring
Detect intruders in the build infrastructure
Do you monitor the build chain for unauthorized access and modifications? Have you completed an attack surface investigation of your build environment? What kinds of actions do you take to narrow the attack vectors?
Assessment questions
- How do you monitor the build chain for unauthorized access and modifications?
- How recently have you completed an attack surface investigation of your build environment?
- What kinds of actions do you take to narrow the attack vectors?
Standard mappings
- CNCF-SSC BP-V Validate runtime security of build workers, SC-SA Use short-lived/ephemeral credentials for machine/service access, A-CE Use a container registry that supports OCI image-spec images
Roles
Unassigned U
U.1 Identify SSC Control Gaps
5
P.3.5 Prevent component vetting bypass
Ensure developers are not bypassing the component vetting process
Audit to ensure developers are consuming components that have gone through the approved vetting process even on their own machines because developer endpoints can become infected. Restrict product build to only packages in the repository of vetted components.
Assessment questions
- In what ways could a developer bypass the component vetting process?
- What are the mechanisms in place to monitor whether developers are consuming third party code through the approved ingestion method and not bypassing the vetting process?
Standard mappings
- S2C2F AUD-2
D.1.5 Emergency artifact fix
Fix a zero-day vulnerability.
Zero-day vulnerabilities may not be fixed by an upstream maintainer in a desired timeframe. Implement an emergency response process to fix the vulnerability, re-build, deploy to your organization, and contribute the fix to the upstream maintainer.
Assessment questions
- How do you handle it when an external artifact has a zero-day vulnerability that is not being fixed by an upstream maintainer in a desired timeframe?
Standard mappings
- S2C2F FIX-1
G.5.5 Support Upstream Dependencies
Sustainable open-source software.
Organizations should be responsible consumers and sustainable contributors to the open-source projects on which they depend. Mechanisms may include donating, paying open-source developers, channeling funds to projects, fundraising for regular audits of critical projects, and having paid staff dedicated to upstream contributions.
Assessment questions
- How do you support the projects providing your upstream dependencies?
Standard mappings
- CLOSING RQ3
E.3.11 Development Environment Scanning Tools
Detect anomalies in the development infrastructure.
Automated scanning tools can detect anomalies and undesired behaviors in each environment, including development, build, testing, and deployment.
Assessment questions
- What tools do you use to secure your development environment? For example, tools to remove viruses, scan files downloaded from the internet before execution, detect signatures of anomalous payloads, and identify changes in configuration settings.
Standard mappings
- CLOSING RQ3
D.1.7 Establish Response Partnerships
Develop external incident information sources through collaboration.
Partners can help during vulnerability response by providing information about compromises, enabling improved response efforts, and collaborating in dealing with attacks. Adversaries are only empowered when no collaboration exists between software organizations.
Assessment questions
- What vulnerability information and incident response relationships do you have with external organizations?
Standard mappings
- CLOSING RQ3
Roles
Contributing standards
Every control above maps to one or more established government and industry standards. See Standards & Frameworks for the full list and which controls cite each one.