Defense Software Assurance Evidence Without Overclaiming: A Guide to Provable Repository Artifacts

Full report

On this page

The Strategic Imperative for Artifact-Based Assurance

The acquisition of software within the United States defense and federal civilian sectors has undergone a foundational transformation, shifting from an environment characterized by trust-based vendor assertions to one demanding cryptographic, artifact-driven verification. Accelerated by a succession of high-profile software supply chain compromises, regulatory mandates such as Executive Order (EO) 14028, and subsequent Office of Management and Budget (OMB) memoranda (M-22-18 and M-23-16), federal agencies and prime contractors are now strictly required to validate the secure development practices of their software suppliers1. This paradigm shift presents a complex operational challenge for highly capable, innovative software engineering suppliers that lack formal enterprise certifications, such as a Cybersecurity Maturity Model Certification (CMMC), a Federal Risk and Authorization Management Program (FedRAMP) Authorization, or a system-specific Authority to Operate (ATO). When evaluating these uncertified suppliers, government program offices and major defense prime contractors require credible, unclassified assurance evidence that the software was designed, built, and delivered securely. Historically, organizations attempted to bridge this gap by loosely adopting compliance terminology, culminating in dangerous overclaiming. A supplier declaring its software "CMMC Level 2 Compliant" or "FedRAMP Authorized" without a formal government sponsor, a third-party assessment organization (C3PAO) audit, and an authorizing official's signature is committing a serious misrepresentation4. The legal and financial risks of such overclaiming are no longer theoretical. The Department of Justice (DOJ) Civil Cyber-Fraud Initiative, launched in October 2021, leverages the False Claims Act (FCA) to pursue contractors and grant recipients that knowingly misrepresent their cybersecurity practices, fail to monitor and report incidents, or provide deficient cybersecurity products6. Enforcement activity under this initiative has escalated rapidly. In fiscal year 2025, the DOJ reported a record $6.8 billion in FCA settlements and judgments, with a substantial portion driven by cybersecurity non-compliance7. Recent enforcement actions underscore the peril of inaccurate compliance assertions. Illumina Inc. agreed to a $9.8 million settlement resolving allegations that it sold genomic sequencing software to federal agencies while failing to patch known vulnerabilities and falsely representing adherence to National Institute of Standards and Technology (NIST) standards6. Defense contractor MORSECORP Inc. settled for $4.6 million after allegedly failing to implement required NIST Special Publication (SP) 800-171 controls and misrepresenting its Supplier Performance Risk System (SPRS) score—a critical metric for defense procurement10. Furthermore, the DOJ has demonstrated a willingness to impose successor liability, holding private equity firms accountable for the cybersecurity failures of their portfolio acquisitions, as evidenced by the $1.75 million settlement involving Aero Turbine Inc. and Gallant Capital Partners7. Given this enforcement climate, software suppliers must clearly delineate between enterprise-level certifications—which they do not possess and cannot legally claim—and repository-provable controls, which they can cryptographically demonstrate. Prime contractors do not require their commercial software library suppliers to possess an organizational ATO; rather, the prime requires the supplier to produce deterministic, machine-readable artifacts that enable the prime's overall system to achieve its own ATO. This report details the specific, public, unclassified assurance evidence that constitutes a credible software supply chain defense, focusing exclusively on artifacts generated directly from the software repository, continuous integration/continuous deployment (CI/CD) pipelines, and public deployment mechanisms.

Delineating Enterprise Certifications from Repository Controls

To construct a credible evidence package, it is imperative to establish the boundary between a software artifact and the enterprise environment in which it is developed, deployed, or operated. Conflating these two domains is the primary cause of supplier overclaiming. Enterprise certifications assess the holistic security posture of an organization or a hosted information system. For example, the Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012 legally mandates that defense contractors protect Controlled Defense Information (CDI) by implementing the 110 security controls detailed in NIST SP 800-171 Rev 213. This requirement forms the basis of CMMC 2.0 Level 215. Similarly, the Federal Acquisition Regulation (FAR) 52.204-21 outlines 15 basic safeguarding controls for Federal Contract Information (FCI), establishing the baseline for CMMC Level 114. These frameworks, alongside the RMF ATO process and FedRAMP, encompass physical facility security, personnel background screening, enterprise-wide incident response capabilities, and organizational network boundary protections. A supplier providing a compiled application binary or an open-source library cannot claim these certifications for their specific product, as the product itself is merely one component operating within a much larger system boundary. Conversely, repository-provable controls are intrinsic properties of the software development lifecycle (SDLC) and the resulting digital artifacts. These controls are evaluated through deterministic outputs that do not rely on organizational audits: cryptographic signatures, automated configuration rules, immutable build logs, and machine-readable dependency manifests. When a prime contractor evaluates a sub-tier supplier, they are seeking evidence that the software was designed securely, built in a hardened, tamper-evident pipeline, and shipped with total transparency regarding its composition and vulnerability posture. Providing this repository-level evidence fulfills the software supply chain requirements of executive mandates and aligns perfectly with the NIST Secure Software Development Framework (SSDF), allowing the supplier to prove maturity without making legally perilous claims about organizational certification status1.

Mapping the Federal Software Assurance Frameworks

To provide evidence that a defense program office will find credible, the supplier's repository artifacts must map directly to the standardized frameworks utilized across the DoD and civilian agencies. Prime contractors utilize these frameworks to translate a supplier's technical outputs into compliance checkboxes for their own overarching enterprise assessments.

NIST Secure Software Development Framework (SSDF)

NIST SP 800-218, widely known as the SSDF version 1.1, serves as the consensus reference standard for secure software engineering across the federal government17. The framework is organized into four core practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV)3. For a software engineering supplier relying on repository-provable evidence, the focus must heavily skew toward the PS and PW domains. For instance, practice PS.1 requires protecting all forms of code from unauthorized access and tampering. In a repository context, this translates directly to strict branch protection rules and cryptographically signed commits18. Practice PW.6 mandates the configuration of the compilation, interpreter, and build processes to increase software security assurance, mapping directly to automated CI/CD pipelines, reproducible builds, and the generation of Software Bill of Materials (SBOMs)19. Compliance with the SSDF is operationalized through the CISA Secure Software Development Attestation Form. EO 14028 and OMB M-22-18 require the CEO or an authorized designee of the software producer to legally attest that their software is developed in environments secured by logged trust relationships, multi-factor authentication, and continuous vulnerability checking2. This form is a legally binding declaration; thus, the supplier must retain the underlying repository artifacts to defend their attestation if scrutinized by the DOJ19.

SLSA and OpenSSF Scorecard

While the NIST SSDF provides high-level policy objectives, the Supply-chain Levels for Software Artifacts (SLSA) and the Open Source Security Foundation (OpenSSF) provide the technical metrics required for implementation. SLSA v1.0 standardizes the technical requirements for software provenance, detailing exactly how a build process should be secured and documented to prevent tampering22. Achieving SLSA Build Level 3, a benchmark increasingly expected by defense primes, requires hermetic, reproducible, and isolated build environments, ensuring that the artifact cannot be maliciously altered during compilation24. The OpenSSF Scorecard is an automated, open-source tool that assesses code repositories against 18 specific security heuristics, assigning a weighted score from 0 to 1026. The Scorecard evaluates critical SDLC hygiene, including the enforcement of branch protection, the requirement for code reviews prior to merging, the presence of dangerous CI workflows, and the utilization of fuzzing and static analysis tools28. For a prime contractor, a high OpenSSF Scorecard output is highly valuable because it provides immediate, mathematically verifiable proof of secure SDLC practices without requiring manual code audits or third-party assessors29.

DoD DevSecOps Reference Design and Iron Bank

The Department of Defense has formalized its approach to modern software acquisition through the DoD Enterprise DevSecOps Fundamentals and related reference designs1. This guidance mandates the structural integration of security controls into CI/CD pipelines, shifting vulnerability detection to build-time and commit-time enforcement1. A central pillar of this strategy is Platform One and its Iron Bank initiative—the DoD's centralized, vetted repository of digitally signed, binary container images33. Software suppliers looking to deploy within DoD environments must align with Iron Bank hardening requirements. Even if a supplier's software is not yet officially hosted in the Iron Bank, delivering artifacts that meet its rigorous Container Approval Record (CAR) standards, pass its Vulnerability Assessment Tool (VAT) scans, and utilize hardened base images ensures seamless reciprocity and accelerates the prime contractor's path to a Continuous Authority to Operate (cATO)33.

Generating Cryptographically Verifiable SDLC Evidence

To assemble a credible reviewer evidence package, the uncertified supplier must focus on the generation, extraction, and presentation of deterministic artifacts. This section exhaustively details the technical mechanisms required to satisfy a prime contractor's rigorous supply chain security review.

Configuration Control, Code Review, and Access Architecture

The foundation of software assurance begins before compilation occurs. The CISA Attestation Form requires suppliers to separate and protect development environments and to log and monitor trust relationships20. In a modern GitOps environment, this translates to strict, API-verifiable repository controls. Suppliers must export their repository configuration settings (e.g., via the GitHub or GitLab REST APIs) to prove that administrative overrides are disabled and that branch protection rules are rigidly enforced on all release branches. The evidence must demonstrate mandatory multi-party review; the Code-Review metric in the OpenSSF Scorecard verifies that pull requests cannot be merged without at least one, and preferably two, independent approvals from authenticated developers26. Status check enforcement must also be evident, proving that commits cannot be merged unless all automated security checks—including static analysis, software composition analysis (SCA), and linting—execute and pass successfully. Furthermore, cryptographic commit signatures are a non-negotiable baseline. Developers must sign commits using GPG, SSH keys, or Sigstore's keyless signing architecture. This cryptographic trail proves the provenance of every line of code back to an authenticated identity, satisfying SSDF PS.1 by protecting code from unauthorized modification40. Access control architectures must also be documented, demonstrating that the principle of least privilege is enforced via identity providers supporting Security Assertion Markup Language (SAML) or OpenID Connect (OIDC), complete with Multi-Factor Authentication (MFA) mandates as explicitly required by EO 1402819.

Deterministic Artifacts and Reproducible Builds

A securely written codebase is effectively neutralized if the build pipeline can be compromised to inject malicious code during compilation—a vector famously exploited during the SolarWinds supply chain attack. Defense primes are consequently demanding absolute proof of build integrity. Suppliers should generate SLSA v1.0 provenance documents during every build cycle22. Utilizing frameworks such as the in-toto attestation framework and the Dead Simple Signing Envelope (DSSE), the CI/CD pipeline generates a cryptographically signed JSON document24. This document details exactly what source code was built, which dependencies were utilized, what environment variables were present, and what specific builder executed the compilation24. Achieving SLSA Build Level 3 requires evidence that this build process runs in an ephemeral, isolated, and hermetic environment—such as a single-use container or virtual machine that possesses no external network access beyond predefined, pinned dependency resolution24. The highest echelon of build assurance, and the most compelling evidence for a defense prime, is deterministic, reproducible compilation. A reproducible build guarantees that compiling the exact same source code with the exact same toolchain yields a byte-for-byte identical binary output43. Because modern compilers often inject timestamps, metadata, or variable file orderings into binaries, canonicalization is required to ensure determinism44. Suppliers should utilize state-of-the-art tools like diffoscope to conduct out-of-band verification44. diffoscope performs deep, byte-level comparisons of binaries, archives, and packages to identify any discrepancies45. Providing a clean diffoscope output demonstrating that a prime contractor can independently clone the source repository and compile a mathematically identical binary is the ultimate proof of supply chain integrity, effectively proving that the supplier's build servers have not been covertly compromised47.

Software Bill of Materials (SBOM) and Dependency Controls

Modern software applications are overwhelmingly composed of third-party open-source libraries. The DoD requires deep, continuous visibility into this dependency tree to rapidly triage zero-day vulnerabilities. Suppliers must automatically generate machine-readable SBOMs during every build using standard federal formats such as CycloneDX or SPDX. This SBOM must be comprehensive, detailing all direct and transitive dependencies, and must be signed to ensure it has not been altered33. Additionally, the OpenSSF Scorecard heavily penalizes projects that do not utilize locked, pinned dependencies28. Suppliers must provide configuration evidence—such as lockfiles (package-lock.json, go.sum, or Cargo.lock)—proving that dependency versions are immutably specified, preventing upstream poisoning attacks39. Evidence of automated dependency update tools, such as Dependabot or Renovate, demonstrates compliance with SSDF PW.4, proving the supplier actively maintains the software's security posture over time26.

Advanced Vulnerability Context: VEX and Reachability Analysis

A significant operational burden for defense primes is the alert fatigue generated by raw SBOMs, which often flag inert vulnerabilities located in deep, unused sub-dependencies. Sophisticated suppliers differentiate themselves by providing advanced vulnerability context alongside their SBOMs. The Vulnerability Exploitability eXchange (VEX) format allows a supplier to cryptographically attest that a specific vulnerability present in a dependency is not reachable or exploitable in the context of the compiled application. Providing VEX documents saves prime contractors hundreds of hours of manual triage. To generate this evidence, advanced suppliers are increasingly utilizing function-level reachability analysis tools, such as Hopper50. Reachability analysis performs deep static analysis, constructing the full application execution flow across first- and third-party code to locate vulnerable functions inside dependencies50. It traces paths from real entry points to those functions; if the vulnerable code path is never called by the application, the vulnerability is flagged as unexploitable50. Providing reachability analysis filters the noise out of vulnerability reports, delivering actionable, evidence-backed intelligence that defense auditors readily accept50.

Secure Development Lifecycle (SDLC) Testing Evidence

The DoD Enterprise DevSecOps Reference Design mandates that security testing must be "shifted left" and fully automated within the CI/CD pipeline1. To prove this, suppliers must export the artifacts generated by these testing suites. Evidence that Static Application Security Testing (SAST) tools execute on every pull request is required to satisfy SSDF PW.5 (Secure Coding Practices)20. Artifacts should include exported reports formatted in the Static Analysis Results Interchange Format (SARIF), allowing the prime contractor to seamlessly ingest the results into their own centralized vulnerability management dashboards. For critical software—particularly those written in memory-unsafe languages like C or C++—fuzzing is an essential control. The OpenSSF Scorecard checks for integration with fuzzing tools like OSS-Fuzz or fast-check26. Supplying fuzzing coverage reports and crash-resolution logs provides irrefutable evidence of deep structural testing and memory safety validation. Finally, Dynamic Application Security Testing (DAST) logs, which record automated scans of the compiled application executing in a staging environment, prove the software's resilience against runtime exploits such as the OWASP Top 10 vulnerabilities.

Release Integrity, Container Hardening, and Supply Chain Assurance

When the software is finally packaged for delivery, its integrity must be irrefutably sealed. SSDF PS.2 explicitly requires a mechanism for verifying software release integrity20.

Cryptographic Release Manifests and Signatures

Every software release must be accompanied by a SHA-256 hash manifest, allowing the receiving prime contractor to verify that the payload was not corrupted or modified in transit. Binaries, container images, and SBOMs must all be cryptographically signed. Modern DevSecOps pipelines leverage tools like Sigstore (Cosign), which enables keyless signing tied directly to OIDC identities23. This approach eliminates the complexities of long-lived cryptographic key management and provides an immutable, public transparency ledger (Rekor) of the signature, satisfying the highest standards of supply chain assurance23.

Iron Bank Alignment and Container Hardening

In modern DoD deployments, software is overwhelmingly packaged and delivered via containers. If a supplier delivers software via containers, they must architect their images to align with Iron Bank hardening requirements33. Suppliers must avoid utilizing bloated operating system bases, such as standard Ubuntu or Debian images, which frequently contain hundreds of baseline Common Vulnerabilities and Exposures (CVEs) before application code is even added52. Instead, they must utilize hardened, minimal bases. Acceptable alternatives include Chainguard Images, Ubuntu Chiseled, Google Distroless, or Red Hat Universal Base Image (UBI) Micro53. These specialized images dramatically reduce the attack surface by stripping out unnecessary components, shell environments, and package managers, ensuring that only the files strictly required to run the application are present53. If a supplier builds upon an existing Iron Bank base image, they can leverage the existing Container Approval Record (CAR). The CAR documents the accepted Risk Management Framework (RMF) justifications for specific Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) applied to that image35. The supplier must provide continuous integration logs proving that their application-layer additions do not violate these underlying STIG configurations—for example, by proving through pipeline checks that the container executes as a non-root user (typically UID 1001\)35.

Operational Readiness Architecture (NIST 800-53/171 Alignment)

While uncertified suppliers cannot provide an ATO for a prime contractor's infrastructure, they must provide software that is architecturally capable of operating within an ATO boundary. The software itself must support the prime's implementation of NIST 800-171 and 800-53 controls37. Providing architectural documentation proving this capability is a critical component of the reviewer evidence package. Access Control (AC Family): The software must not rely exclusively on localized, hardcoded credential management. Evidence must be provided detailing how the software integrates with enterprise identity providers via SAML 2.0, OAuth2, or OIDC, allowing the prime to enforce centralized MFA and session timeouts. Furthermore, the software must support fine-grained Role-Based Access Control (RBAC), enabling the prime to restrict access to specific functions based on user authorization levels5. Audit Logging and Accountability (AU Family): To support continuous monitoring and incident response, the software architecture documentation must prove that it generates comprehensive, structured logs (such as JSON formatted event data) for all security-relevant events. This includes authentication successes and failures, privilege escalations, configuration changes, and data exports. The software must support externalizing these logs to centralized Security Information and Event Management (SIEM) systems via standard protocols like Syslog or Fluentd15. Backup, Recovery, and Contingency Planning (CP Family): A prime contractor is responsible for the availability and recovery of the system. The software supplier must provide documentation of automated backup hooks, deterministic database dump utilities, and state-restoration playbooks. This evidence assures the prime that the software supports rapid recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) in the event of a catastrophic failure or ransomware event. Web Security Headers and Application Defenses: For web-based applications, the supplier must provide dynamic scanning evidence proving the enforcement of strict HTTP security headers. Artifacts must verify the presence of Content-Security-Policy (CSP) to mitigate Cross-Site Scripting (XSS), HTTP Strict Transport Security (HSTS) to force encrypted connections, and X-Frame-Options to prevent clickjacking attacks. Accessibility (Section 508): While not strictly a cybersecurity control, Section 508 accessibility compliance is a hard legal requirement for federal software deployments. A mature engineering organization demonstrates operational readiness by supplying a Voluntary Product Accessibility Template (VPAT) generated from automated accessibility scans, proving the software is ready for federal civilian and defense personnel usage.

Administrative Assurance and Evidence Retention

The technical artifacts detailed above must be supported by mature administrative processes to ensure the software remains secure throughout its lifecycle. A prime contractor requires proof that the supplier possesses a formal process for handling newly discovered vulnerabilities. The supplier must provide a publicly accessible Vulnerability Disclosure Policy (VDP) and a documented incident response Service Level Agreement (SLA) detailing exactly how rapidly patches will be issued for critical CVEs55. This is vital because DFARS 252.204-7012 mandates rapid 72-hour cyber incident reporting to the DoD13. If a zero-day vulnerability is discovered in the supplier's software, the prime contractor relies on the supplier's rapid response to meet their own 72-hour regulatory window. Furthermore, the generation of this evidence is a critical legal defense under the False Claims Act. When a prime contractor incorporates a supplier's software, the prime assumes the risk of that software's compliance posture. To mitigate legal liability, the uncertified supplier must rigorously practice evidence retention. The CISA Attestation form is a legally binding document, and the signing executive is expected to retain the underlying artifacts that justify the signature19. The supplier must maintain an immutable, long-term archive of CI/CD pipeline logs, SLSA provenances, diffoscope outputs, and SARIF scan results. This archive must be retained for a minimum period—typically aligned with the software's support lifecycle or the overarching contract terms—to serve as defensive documentation in the event of a Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) audit or a DOJ whistleblower allegation5.

Recommended Reviewer Evidence Package for Prime Contractors

To facilitate a frictionless, rapid review process with a government program office or prime contractor, the uncertified software supplier should compile the aforementioned artifacts into a standardized, machine-readable repository. This "Reviewer Evidence Package" must explicitly avoid claiming organizational ATOs or CMMC status, focusing entirely on repository-provable software assurance.

The modern defense acquisition environment has evolved far beyond the point where subjective enterprise security questionnaires and broad claims of compliance are deemed sufficient. With the specter of the False Claims Act looming over the Defense Industrial Base, prime contractors require definitive, cryptographic proof of software security. For software engineering suppliers lacking formal ATOs or enterprise certifications, the path to federal integration lies in absolute technical transparency. By weaponizing repository-provable controls—generating SLSA provenance, automating comprehensive SBOMs, proving build determinism via diffoscope, and adopting rigorous container hardening practices—uncertified suppliers can deliver a level of artifact assurance that frequently exceeds that of traditionally certified legacy organizations. This deterministic, evidence-based approach protects both the supplier and the prime from legal liability, ensuring that only resilient, tamper-evident software enters the critical defense supply chain.

Works cited

1. DevSecOps Practices and Implementation, https://applicationsecurityauthority.com/devsecops-practices/

2. (CISA) Secure Software Development Attestation Form Instructions, https://detegoglobal.com/wp-content/uploads/2024/09/CISA-Secure-Software-Development-Attestation-Form.pdf

3. SSDF Audit & Attestation Services | NIST SP 800-218 Compliance, https://lazarusalliance.com/ssdf-security-control-assessment-validation-services/

4. A Small Business Guide to CMMC Compliance (2026), https://www.totem.tech/cmmc-compliance-small-business-guide/

5. CMMC Checklist: Audit Prep Guide for DoD Contractors \- SentinelOne, https://www.sentinelone.com/cybersecurity-101/cybersecurity/cmmc-checklist/

6. Cybersecurity-Related Enforcement Under the False Claims Act in, https://www.mintz.com/insights-center/viewpoints/2406/2026-01-13-cybersecurity-related-enforcement-under-false-claims-act

7. DOJ Cyber-Fraud Settlements Surge 233% in 2025 \- Fluet law firm, https://fluet.law/doj-cyber-fraud-settlements-surge-233-in-2025-what-government-contractors-need-to-know/

8. False Claims Act Enforcement in 2026 \- Foley & Lardner LLP, https://www.foley.com/insights/publications/2026/03/false-claims-act-enforcement-in-2026-2/

9. DOJ Settles Cybersecurity FCA Claims With PE Firm and, https://www.gtlaw.com/-/media/files/insights/alerts/2025/08/gt-alert\_doj-settles-cybersecurity-fca-claims-with-pe-firm-and-government-contractors.pdf?rev=26f5fbdc14cd445490a5dcf0bf4ae071

10. Cybersecurity Enforcement in 2025: DOJ Steps Up Action, https://www.dwlaw.com/news-alerts/cyber-risk-real-consequences

11. DOJ's Civil-Cyber Fraud Initiative Strikes Again: DOD Contractor, https://www.arnoldporter.com/en/perspectives/blogs/fca-qui-notes/posts/2025/04/civil-cyber-fraud-initiative-strikes-again

12. The DOJ's Civil Cyber-Fraud Initiative, Part 1: A Wake-Up Call for, https://www.americanbar.org/groups/business\_law/resources/business-law-today/2023-july/doj-civil-cyber-fraud-initiative-part-1/

13. OSC Resources \- Business Transformation Institute, https://www.biztransform.net/osc-resources/

14. GovCon Cybersecurity & Compliance Hub: CMMC, NIST & CUI, https://gsconsultingllc.com/insights/govcon-cybersecurity-compliance-hub

15. Cybersecurity Maturity Model Certification (CMMC) Compliance, https://hyperproof.io/cmmc-compliance-complete-guide/

16. Cybersecurity Maturity Model Certification (CMMC) Version .6, https://www.governmentcontractslaw.com/2019/11/cybersecurity-maturity-model-certification-cmmc-version-6-another-step-on-the-department-of-defenses-long-and-winding-cybersecurity-road/

17. Secure Software Development Framework (SSDF) \- NIST CSRC, https://csrc.nist.gov/projects/ssdf

18. NIST SSDF (SP 800-218) Framework Reference | SecPortal, https://secportal.io/frameworks/nist-ssdf

19. NIST SP 800-218 (SSDF) \- Keyfactor, https://www.keyfactor.com/compliance-hub/nist-sp-800-218-ssdf/

20. Explore NIST SP 800-218 and CISA Attestation Requirements, https://www.sonatype.com/resources/guides/stay-compliant-nist-sp-800-218-cisa-requirements

21. NIST SP 800-218 JFROG PLATFORM COMPLIANCE GUIDE, https://media.jfrog.com/wp-content/uploads/2024/05/25205316/NIST-SP-800-218-Compliance-Guide-v1.3.pdf

22. TOP 10 SECURE SOFTWARE SUPPLY CHAIN ATTESTATION, https://www.bestdevops.com/top-10-secure-software-supply-chain-attestation-tools-slsa-provenance/

23. sigstore \- Open Source Security Foundation, https://openssf.org/tag/sigstore/

24. How to Implement SLSA Level 3 Build Provenance for Kubernetes, https://oneuptime.com/blog/post/2026-02-09-slsa-level3-build-provenance/view

25. SLSA \-- GitLab Public Sector reference, https://gitlab-com.gitlab.io/public-sector/reference/compliance/frameworks/slsa/

26. OpenSSF Scorecard: On the Path Toward Ecosystem-wide ... \- arXiv, https://arxiv.org/pdf/2208.03412

27. Security Scorecards for Open Source Software \- alphasec, https://alphasec.io/security-scorecards-for-open-source-software/

28. OpenSSF Scorecard, https://scorecard.dev/

29. How mature is this repository? My long quest for open-source, https://www.foo.be/2026/08/Open-Source-Metrics.html

30. OpenSSF Scorecard \- Security health metrics for Open Source, https://github.com/ossf/scorecard

31. DoD Enterprise DevSecOps Fundamentals, https://dodcio.defense.gov/Portals/0/Documents/Library/DoD%20Enterprise%20DevSecOps%20Fundamentals%20v2.5.pdf

32. Software Developmental Test and Evaluation in DevSecOps, https://www.cto.mil/wp-content/uploads/2025/01/Software\_DTE\_DEVSECOPS\_GB\_Jan2025\_Signed.pdf

33. Iron Bank \- Platform One, https://p1.dso.mil/ironbank

34. Platform One \- Catalyst Campus, https://catalystcampus.org/wp-content/uploads/2022/01/Iron-Bank-Slick-Sheet.pdf

35. Platform One Iron Bank: Container Hardening Guide \- Rutagon, https://rutagon.com/insights/platform-one-iron-bank-compliance/

36. Nist SP 800-171 PDF \- Scribd, https://www.scribd.com/document/358927570/NIST-SP-800-171-pdf

37. Changelog \- Evidentia, https://docs.evidentiagrc.com/6-project/changelog/

38. NIST.SP.800-53r5.pdf, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf

39. OpenSSF Scorecard for .NET and the NuGet ecosystem, https://devblogs.microsoft.com/dotnet/openssf-scorecard-for-net-nuget/

40. Securing the Software Supply Chain \- CISA, https://www.cisa.gov/sites/default/files/publications/ESF\_SECURING\_THE\_SOFTWARE\_SUPPLY\_CHAIN\_DEVELOPERS.PDF

41. NIST SSDF Implementation Guide: Practical SP 800-218 Walkthrough, https://secportal.io/blog/nist-ssdf-implementation-guide

42. SLSA Provenance Hands-on: Generate with GitHub Actions, Verify, https://dev.to/kanywst/slsa-provenance-hands-on-generate-with-github-actions-verify-with-slsa-verifier-56ka

43. Causes and Canonicalization of Unreproducible Builds in Java \- arXiv, https://arxiv.org/html/2504.21679v4

44. Causes and Canonicalization of Unreproducible Builds in Java, https://www.researchgate.net/publication/397224045\_Causes\_and\_Canonicalization\_of\_Unreproducible\_Builds\_in\_Java

45. Debian 14 Makes Reproducible Builds Mandatory for Linux Packages, https://linuxsecurity.com/features/debian-reproducible-builds

46. Gartner Software Engineering Mitigate Software Supply Chain, https://www.digicert.com/content/dam/digicert/pdfs/datasheet/software-engineer-leaders-mitigate-ssc-risks.pdf

47. Sscsp \- CNCF TAG Security \- Cloud Native Computing Foundation, https://tag-security.cncf.io/community/working-groups/supply-chain-security/supply-chain-security-paper/sscsp/

48. Fully Countering Trusting Trust through Diverse Double-Compiling, https://dwheeler.com/trusting-trust/

49. Modernizing Federal DevSecOps for CMMC and Beyond \- Sonatype, https://www.sonatype.com/blog/modernizing-federal-devsecops-for-cmmc-and-beyond

50. Delivering Precision Container Security with Function-Level, https://www.hopper.security/post/function-level-reachability-for-containers

51. Iron Bank Image Signing | P1 Docs, https://p1docs.dso.mil/iron-bank/tutorials/cosign

52. Iron Bank's Weak Link: The Myth of Hardened Container Security, https://www.threatintelligence.com/blog/container-security

53. Chainguard Alternatives: Best Hardened Image Providers 2026, https://www.minimus.io/post/chainguard-alternatives-hardened-image-providers

54. What if your container images were security-maintained at the source?, https://ubuntu.com/blog/what-if-your-container-images-were-security-maintained-at-the-source

55. Software Supply Chain and DevOps Security Practices \- NCCoE, https://www.nccoe.nist.gov/sites/default/files/2022-11/dev-sec-ops-project-description-final.pdf