+5.3 Existing frameworks and initiatives

5.3 Existing frameworks and initiatives

The ecosystem of machine-processable security has been rapidly evolving. Some of the key initiatives

include foundational frameworks like NIST’s Open Security Controls Assessment Language (OSCAL) (compliance as code), OWASP’s CycloneDX Attestations (CDXA) (native security

attestation) and SPDX 3.0 Security Profile , which provide the structural grammar for automating compliance and supply-chain transparency. Presented below are some of these initiatives in this area.

  • OSCAL (21) . Developed by NIST, OSCAL is the premier model for compliance as code. It provides a standardised way to express security control catalogues, system security plans and assessment results. By using OSCAL, organisations can automate the generation of compliance documentation, allowing for continuous authorisation, whereby the status of security controls is updated in real-time as evidence is collected.
  • CycloneDX (OWASP ECMA-424) (22) . While originally an SBOM format, CycloneDX has expanded into a full-stack transparency standard. Its attestation capabilities (CDXA) allow organisations to document claims about security requirements alongside generating a bill of materials. It also includes specialised modules like VEX to communicate whether a vulnerability actually affects a product, and it can produce a cryptographic bill of materials (CBOM) to inventory cryptographic assets for quantum readiness. CycloneDX Assessors Studio (23) provides an emerging open-source implementation for conducting structured assessments, collecting evidence, documenting claims and generating CycloneDX attestations.
  • SDPX 3.0 Security Profile (24) . The security profile captures security-related information in a SPDX Security Document. Specifically, the properties and relationships specified in the security profile are in support of exchanging information about system vulnerabilities that may exist, the severity of those vulnerabilities, and a mechanism to express how a vulnerability may affect a specific element including if a fix is available.
  • The Open Source Security Foundation (OpenSSF). OpenSSF leads several projects, including Security Insights (25), a specification that project teams can use to report security facts (like bug bounty information or security contacts) in a machine-processable YAML format. They also champion the OpenSSF Scorecard (26), which automatically assesses open-source projects against security best practices. OpenSSF Best Practices badge (27) provides machine-readable security criteria status for many OSS projects, including against the OpenSSF Baseline (28). Supply-chain Levels for Software Artifacts, or SLSA (29) (“salsa”) provides recommended machine-readable schemas for SLSA attestations.
  • OWASP (Open Web Application Security Project). Beyond CycloneDX, OWASP projects like the ASVS (30) (Application Security Verification Standard) provide the underlying requirements that these machine-readable formats aim to verify. Newer initiatives like the MLSVS (Machine Learning Security Verification Standard) are extending these principles into the AI/ML domain.
  • TC54 (Ecma International) (31): This technical committee is the formal standardisation body for CycloneDX. It focuses on the Transparency Exchange API, which aims to standardise how software transparency information (like SBOMs and attestations) is discovered and shared across the global supply chain.
  • in-toto (32) . in-toto provides an open framework for expressing verifiable claims about software supply-chain activities. SLSA Provenance uses in-toto to describe where, when and how software artefacts were built and tools such as Sigstore Cosign (33) can sign and verify in-toto attestations.
  • Device Security Passport (34) . The Device Security Passport (DSP) is intended to provide a structured, machine-readable record that consolidates relevant security information about an IoT component and makes it accessible to stakeholders across the supply chain.

1. Prehľad

Názov Štandard

1.1 Odkazy

1.2 Identifikované požiadavky

1.3 Súvisiace predpisy

2. Identifikované požiadavky

Požiadavky
Zdroj Požiadavka

3. Súvisiace predpisy

Predpisy
Zdroj Regulácia