Generating and Safeguarding Artifacts for SSDF Attestation

blogs / February 01, 2024

Generating and Safeguarding Artifacts for SSDF Attestation

Federal agencies are increasingly requiring CSPs to follow the practices in the NIST Secure Software Development Framework (SSDF), as we explained in a previous blog post. As these requirements take effect, CSPs will need to either self-attest to following the SSDF practices or have their Third-Party Assessment Organization (3PAO) audit their compliance with the practices and attest to compliance.

Whether you’re planning on self-attestation or a 3PAO audit and attestation, you’ll need to generate and safeguard artifacts – pieces of evidence – of following the SSDF practices. The same OMB Memorandum (M-22-18) that is causing federal agencies to require CSPs to follow the SSDF also authorizes Federal agencies to request that CSPs provide artifacts supporting SSDF attestations. CSPs also need artifacts to demonstrate to themselves (for self-attestation) or a 3PAO (for audit purposes) that they’re truly following the practices.

Understanding Artifacts of SSDF Conformance

Executive Order (EO) 14028 directed NIST to develop and issue several publications on “identifying practices that enhance the security of the software supply chain.” One of these publications, Software Supply Chain Security Guidance Under EO 14028, focuses on SSDF conformance and the necessary artifacts. It defines two types of artifacts: low-level and high-level.

Low-level artifacts are generated throughout the software development process to record the actions taken and the results of modeling, scans, tests, and other assessments of software security. Low-level artifacts also include the software’s source code and related components.
High-level artifacts can be thought of as summaries of the secure software development practices that a software-developing organization has followed. A high-level artifact could be a white paper, webpage, or other narrative describing how the organization conducts its secure software development. The intention is for the high-level artifacts to be consistent with and supported by the low-level artifacts.

NIST’s guidance builds on these definitions to provide recommendations for federal agencies on how software developers could attest to conformity with the SSDF’s practices. One of these recommendations encourages agencies to request high-level artifacts, not low-level, to meet the requirements of EO 14028. It would be overwhelming for both CSPs and federal agencies if agencies had to review every log file, scan report, and other low-level artifact for each piece of software. However, NIST’s guidance acknowledges that agencies might need to see particular low-level artifacts to satisfy other requirements they have.

Tips for Artifact Generation and Safeguarding

Here are three tips for CSPs preparing to generate and safeguard low-level and high-level artifacts for SSDF attestation purposes.

Automate low-level artifact generation and safeguarding into your existing development processes as much as possible. Many low-level artifacts, such as event logs for development systems and software, and software vulnerability scanning results, should be automatically generated at all times. These artifacts should be protected to prevent anyone from altering or deleting them, and they should be securely retained for the appropriate length of time, potentially years—that alone can present significant challenges. You may need to acquire or create additional software or services to generate and safeguard any other low-level artifacts that should be generated on an ongoing basis. You may also need to acquire artifacts from other systems, such as the technologies securing and protecting development environments and endpoints.
Have processes in place to manually create any other artifacts you need. Low-level artifacts are needed for all SSDF practices throughout the entire software development lifecycle. Artifacts must include preparatory activities such as identifying cybersecurity requirements, creating policies, defining roles and responsibilities, and conducting secure software development-related training. Artifacts also must be generated later in the lifecycle, such as when making security architecture decisions in meetings or performing manual code reviews. For human-performed activities, low-level artifacts often need to be manually documented in meeting minutes, reports, or other forms so they can be saved and preserved. And don’t forget the need to write high-level artifacts summarizing your development practices so you can post them publicly or share them as needed with prospective and current customers.
Avoid sharing low-level artifacts with federal agencies; share high-level artifacts instead. Federal agencies are likely to request high-level artifacts only. Low-level artifacts are usually not requested because of the immense challenges they involve. Low-level artifacts often contain sensitive internal information, comprise huge volumes of data, and are hard to understand out of context. Also, low-level artifacts provide a snapshot of what occurred at particular moments, not the big-picture view of development practices that high-level artifacts can provide. If you are required to share low-level artifacts, make sure to sanitize them appropriately to avoid sharing sensitive internal information.

Partnering with an outside auditor and/or consultant to assist with devising, deploying, and verifying your company’s generation and safeguarding of low-level and high-level artifacts for SSDF attestation purposes could be beneficial. Consultants can aid CSPs in understanding federal agency requirements and implementing the secure software development practices needed to effectively and efficiently meet those requirements.

If you have any questions or need assistance in implementing the generation and safeguarding of SSDF artifacts, contact us at info@infusionpoints.com!