> For the complete documentation index, see [llms.txt](https://docs.xygeni.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xygeni.io/xygeni-products/compliance/compliance-scanner/supported-compliance-standards.md).

# Supported compliance standards

### CIS Software Supply Chain Security benchmark <a href="#cis_software_supply_chain_security_benchmark" id="cis_software_supply_chain_security_benchmark"></a>

The [CIS Software Supply Chain Security benchmark](https://workbench.cisecurity.org/files/3972/download/5064) provides prescriptive guidance for establishing a secure configuration posture for Software Development Platforms and Pipelines.

CIS Benchmarks are best practices for the secure configuration of a target system. In this case, the target system is the software supply chain.

{% hint style="info" %}
Visit [CIS Software Supply Chain Security benchmark](https://detectorsdev.xygeni.io/xydocs/compliance/cis_sscs.html) for further details.
{% endhint %}

### OWASP Software Component Verification Standard <a href="#owasp_software_component_verification_standard" id="owasp_software_component_verification_standard"></a>

The *Software Component Verification Standard* (SCVS) is a community-driven effort to establish a framework for identifying activities, controls, and best practices, which can help in identifying and reducing risk in a software supply chain.

{% hint style="info" %}
Visit [OWASP Software Component Verification Standard](https://detectorsdev.xygeni.io/xydocs/compliance/owasp_scvs.html) for further details.
{% endhint %}

### OpenSSF FLOSS

The [OpenSSF FLOSS Best Practices](https://bestpractices.coreinfrastructure.org/en/criteria) is a set of recommendations from the Open Source Security Foundation (OpenSSF) [Best Practices Working Group](https://github.com/ossf/wg-best-practices-os-developers) to help open source developers create and maintain more secure software.

The best practices criteria are divided into three levels, for an incremental adoption:

* **Passing** focuses on best practices that well-run FLOSS projects typically already follow. Getting the passing badge is an achievement; at any one time only about 10% of projects pursuing a badge achieve the passing level.
* **Silver** is a more stringent set of criteria than passing but is expected to be achievable by small and single-organization projects.
* **Gold** is even more stringent than silver and includes criteria that are not achievable by small or single-organization projects.

{% hint style="info" %}
Visit [OpenSSF FLOSS Best Practices Badge](https://detectorsdev.xygeni.io/xydocs/compliance/openssf_flossbp.html) for further details.
{% endhint %}

### OpenSSF Scorecard <a href="#openssf_scorecard" id="openssf_scorecard"></a>

[OpenSSF Scorecards](https://github.com/ossf/scorecard) is an automated tool that assesses a number of important heuristics ("checks") associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce, and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.

{% hint style="info" %}
Visit [OpenSSF Scorecards](https://detectorsdev.xygeni.io/xydocs/compliance/openssf_scorecard.html) for further details.
{% endhint %}

### ESF Securing the Software Supply Chain DEV

The [ESF Securing the Software Supply Chain - Recommended Practices for Developers](https://www.cisa.gov/uscert/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF) is a set of guidelines aimed at improving the security of software development by reducing the risk of supply chain attacks.

The set of recommended principles are framed in 5 top-level sections:

* Secure product criteria and management
* Develop Secure Code
* Verify Third-Party Components
* Harden the Build Environment
* Deliver Code

By following these guidelines, software developers can reduce the risk of supply chain attacks and ensure the security and integrity of their software.

{% hint style="info" %}
Visit [ESF Securing the Software Supply Chain. Recommended Practices for Developers](https://detectorsdev.xygeni.io/xydocs/compliance/esf_s3c_dev.html) for further details.
{% endhint %}

### Post-quantum cryptography (PQC) standards

These standards map your cryptographic inventory to the post-quantum transition mandates. They require a cryptographic inventory ([CBOM](/xygeni-products/quantum-safe-compliance.md)) as input — supplied with `--cbom` or computed on demand. Each checks that a cryptographic inventory exists and that no quantum-vulnerable cryptography remains relative to the regime's timeline. See [Quantum-Safe Compliance & CBOM](/xygeni-products/quantum-safe-compliance.md) for the requirements behind them.

#### NIST IR 8547 - Transition to Post-Quantum Cryptography Standards

NIST IR 8547 sets the timeline for retiring quantum-vulnerable public-key cryptography: deprecated by 2030 and disallowed after 2035. Hybrid (classical + PQC) constructions are permitted during the transition.

{% hint style="info" %}
Visit [NIST IR 8547 PQC Transition](https://detectorsdev.xygeni.io/xydocs/compliance/nist_pqc_transition.html) for further details.
{% endhint %}

#### NSA CNSA 2.0

The NSA Commercial National Security Algorithm Suite 2.0 mandates pure post-quantum algorithms for national security systems — default by 2030 and exclusive by 2033, with hybrid constructions not approved as an end state.

{% hint style="info" %}
Visit [NSA CNSA 2.0](https://detectorsdev.xygeni.io/xydocs/compliance/cnsa_2_0_pqc.html) for further details.
{% endhint %}

#### EU PQC Roadmap

The EU Coordinated Implementation Roadmap for the transition to post-quantum cryptography expects governance and a cryptographic inventory from 2026, high-risk use cases migrated by 2030, and all systems by 2035, with hybrid constructions encouraged during the transition.

{% hint style="info" %}
Visit [EU PQC Roadmap](https://detectorsdev.xygeni.io/xydocs/compliance/eu_pqc_roadmap.html) for further details.
{% endhint %}

#### PCI DSS 4.0 (Post-Quantum)

PCI DSS 4.0 requirement 12.3.3 mandates a documented, periodically-reviewed cryptographic cipher-suite inventory. PCI DSS sets no post-quantum deadline, so quantum-vulnerable cryptography is surfaced as advisory migration debt rather than a dated failure. This is a PQC-scoped subset, not a full PCI DSS assessment.

{% hint style="info" %}
Visit [PCI DSS 4.0 PQC](https://detectorsdev.xygeni.io/xydocs/compliance/pci_dss_4_pqc.html) for further details.
{% endhint %}

#### DORA (Post-Quantum)

The EU Digital Operational Resilience Act (Art. 9) requires ICT cryptographic controls and a key-management/encryption policy — implying a cryptographic inventory. DORA sets no post-quantum deadline, so quantum-vulnerable cryptography is surfaced as advisory migration debt. This is a PQC-scoped subset, not a full DORA assessment.

{% hint style="info" %}
Visit [DORA PQC](https://detectorsdev.xygeni.io/xydocs/compliance/dora_pqc.html) for further details.
{% endhint %}

#### NIS2 (Post-Quantum)

The EU NIS2 Directive (Art. 21) requires policies on the use of cryptography and encryption — implying a cryptographic inventory. NIS2 sets no post-quantum deadline, so quantum-vulnerable cryptography is surfaced as advisory migration debt. This is a PQC-scoped subset, not a full NIS2 assessment.

{% hint style="info" %}
Visit [NIS2 PQC](https://detectorsdev.xygeni.io/xydocs/compliance/nis2_pqc.html) for further details.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.xygeni.io/xygeni-products/compliance/compliance-scanner/supported-compliance-standards.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.