Where software trust is defined and measured
Code Trust Assurance Intelligence — creating public trust in the modern software supply chain. Six domains, 86 controls, five maturity levels, and a single 0–100 Trust Score.
Each domain is a trust boundary
Domain weights reflect their relative impact on overall software trust posture. Together they span identity, integrity, development, dependencies, runtime, and governance.
Identity & Provenance
Identity & Provenance
Developer and build identity cryptography, SBOM generation, contributor trust weighting, AI-generated code attribution, and cross-organisation identity federation.
Integrity & Immutability
Integrity & Immutability
Artifact signing, build provenance attestation, reproducible builds, immutable artifact storage, SLSA level achievement, and binary transparency logging.
Secure Development Practices
Secure Development Practices
Threat modeling, SAST/DAST/IAST/RASP integration, secure coding standards, developer security training, Security Champions Programme, and penetration testing.
Dependency & Supply Chain
Dependency & Supply Chain
CVE monitoring, dependency risk scoring, patch SLA management, private registry controls, SBOM-CVE correlation, and supplier contractual security obligations.
Runtime Behavior Assurance
Runtime Behavior Assurance
Runtime anomaly detection, behavioural baselines, drift detection, container runtime security, process behavior analytics, and runtime Trust Score updates.
Governance & Accountability
Governance & Accountability
CTA Governance Charter, executive accountability assignment, RACI matrix, audit trail management, policy-as-code enforcement, and regulatory compliance mapping.
All 86 controls, searchable
Filter by domain or search by control ID, name, or what it assesses. This is the same control set an assessment scores independently, L1–L5.
| ID | Control | What it assesses | Evidence | Min. maturity | Relevance |
|---|---|---|---|---|---|
| D1-01 | Developer identity verification NIST SSDFSLSAin-toto | Every committer is cryptographically bound to a verified real-world identity. | T3 | L2+ | CTA-1 |
| D1-02 | Cryptographic commit signing NIST SSDFSLSAin-toto | Commits are signed and signatures are enforced at merge time. | T1 | L2+ | CTA-1 |
| D1-03 | Contribution attribution & audit trail NIST SSDFSLSAin-toto | Every change traces to an accountable author with an immutable log. | T3 | L2+ | CTA-1 |
| D1-04 | Signing key lifecycle management NIST SSDFSLSAin-toto | Signing keys are issued, rotated, escrowed, and revoked under policy. | T1 | L2+ | CTA-1 |
| D1-05 | Build identity attestations NIST SSDFSLSAin-toto | CI/CD builders assert their identity via signed attestations. | T1 | L2+ | CTA-1 |
| D1-06 | Pipeline identity & credentials NIST SSDFSLSAin-toto | Pipeline workloads use short-lived, scoped, auditable credentials. | T3 | L2+ | CTA-1 |
| D1-07 | Automated SBOM generation NIST SSDFSLSAin-toto | A Software Bill of Materials is produced automatically for every build. | T1 | L2+ | CTA-1 |
| D1-08 | SBOM lifecycle management NIST SSDFSLSAin-toto | SBOMs are versioned, stored, and kept current across releases. | T1 | L2+ | CTA-1 |
| D1-09 | Component origin verification NIST SSDFSLSAin-toto | The provenance of each component is verified before it enters a build. | T3 | L2+ | CTA-1 |
| D1-10 | Contributor trust weighting NIST SSDFSLSAin-toto | Contributions are risk-weighted by contributor history and trust level. | T3 | L2+ | CTA-1 |
| D1-11 | External contributor vetting NIST SSDFSLSAin-toto | Outside contributors are screened before code is accepted. | T3 | L2+ | CTA-1 |
| D1-12 | Credential revocation NIST SSDFSLSAin-toto | Compromised or stale identities and keys are revoked rapidly. | T3 | L2+ | CTA-1 |
| D1-13 | Trust Lineage Graph NIST SSDFSLSAin-toto | A graph links identity, provenance, and integrity across the lifecycle. | T3 | L4+ | CTA-3 |
| D1-14 | AI-generated code attribution NIST SSDFSLSAin-toto | AI-authored code is labelled, attributed, and trust-classified. | T3 | L4+ | CTA-3 |
| D1-15 | Federated identity standards NIST SSDFSLSAin-toto | Identity federates across organisations using open standards. | T1 | L5+ | CTA-4 |
| D2-01 | Signed commits enforcement SLSAin-totoEU CRA | Unsigned commits are blocked from protected branches. | T1 | L3+ | CTA-2 |
| D2-02 | Artifact signing SLSAin-totoEU CRA | Release artifacts are cryptographically signed before distribution. | T1 | L3+ | CTA-2 |
| D2-03 | Build provenance attestation SLSAin-totoEU CRA | Builds emit verifiable provenance describing how they were produced. | T1 | L3+ | CTA-2 |
| D2-04 | Tamper-evident pipeline SLSAin-totoEU CRA | Pipeline steps are recorded so tampering is detectable. | T3 | L3+ | CTA-2 |
| D2-05 | Reproducible builds SLSAin-totoEU CRA | Builds are bit-for-bit reproducible from source. | T1 | L5+ | CTA-4 |
| D2-06 | Immutable artifact storage SLSAin-totoEU CRA | Published artifacts cannot be silently altered or replaced. | T1 | L3+ | CTA-2 |
| D2-07 | Pipeline integrity monitoring SLSAin-totoEU CRA | Pipeline configuration and integrity are continuously monitored. | T2 | L3+ | CTA-2 |
| D2-08 | Dependency hash verification SLSAin-totoEU CRA | Dependencies are verified against known-good cryptographic hashes. | T1 | L3+ | CTA-2 |
| D2-09 | Release integrity gates SLSAin-totoEU CRA | Releases must pass integrity checks before promotion. | T3 | L3+ | CTA-2 |
| D2-10 | Container image signing SLSAin-totoEU CRA | Container images are signed and verified at deploy time. | T1 | L3+ | CTA-2 |
| D2-11 | Package hash verification SLSAin-totoEU CRA | Package contents are hash-verified on install. | T1 | L3+ | CTA-2 |
| D2-12 | Integrity exception governance SLSAin-totoEU CRA | Integrity exceptions are formally approved and time-bounded. | T3 | L3+ | CTA-2 |
| D2-13 | in-toto framework adoption SLSAin-totoEU CRA | Supply-chain steps are attested using the in-toto framework. | T1 | L3+ | CTA-2 |
| D2-14 | SLSA level achievement SLSAin-totoEU CRA | Build integrity is measured against SLSA build levels. | T1 | L4+ | CTA-3 |
| D2-15 | Binary transparency logging SLSAin-totoEU CRA | Released binaries are recorded in a public transparency log. | T1 | L5+ | CTA-4 |
| D3-01 | Threat modelling NIST SSDFOWASP SAMM v2ISO 27001 | Systems are threat-modelled before and during development. | T3 | L3+ | CTA-2 |
| D3-02 | Security requirements definition NIST SSDFOWASP SAMM v2ISO 27001 | Security requirements are defined alongside functional ones. | T3 | L3+ | CTA-2 |
| D3-03 | Secure coding standards NIST SSDFOWASP SAMM v2ISO 27001 | Enforced secure-coding standards guide all development. | T3 | L3+ | CTA-2 |
| D3-04 | Security training (role-specific) NIST SSDFOWASP SAMM v2ISO 27001 | Engineers receive security training tailored to their role. | T3 | L3+ | CTA-2 |
| D3-05 | SAST as CI/CD gate NIST SSDFOWASP SAMM v2ISO 27001 | Static analysis runs as a blocking gate in the pipeline. | T2 | L3+ | CTA-2 |
| D3-06 | DAST integration NIST SSDFOWASP SAMM v2ISO 27001 | Dynamic testing exercises running applications for flaws. | T2 | L3+ | CTA-2 |
| D3-07 | IAST & RASP deployment NIST SSDFOWASP SAMM v2ISO 27001 | Interactive and runtime protection instrument live code paths. | T2 | L4+ | CTA-3 |
| D3-08 | Fuzz testing programme NIST SSDFOWASP SAMM v2ISO 27001 | Fuzzing continuously probes inputs for undiscovered defects. | T2 | L4+ | CTA-3 |
| D3-09 | Security peer review NIST SSDFOWASP SAMM v2ISO 27001 | Security-focused peer review is required before merge. | T3 | L3+ | CTA-2 |
| D3-10 | Pre-commit security hooks NIST SSDFOWASP SAMM v2ISO 27001 | Local hooks catch secrets and issues before commit. | T3 | L3+ | CTA-2 |
| D3-11 | Security Champions programme NIST SSDFOWASP SAMM v2ISO 27001 | Embedded champions drive security within each team. | T3 | L3+ | CTA-2 |
| D3-12 | Security requirements traceability NIST SSDFOWASP SAMM v2ISO 27001 | Requirements trace to tests and implemented controls. | T3 | L3+ | CTA-2 |
| D3-13 | AI-generated code review policy NIST SSDFOWASP SAMM v2ISO 27001 | AI-generated code undergoes enhanced, documented review. | T3 | L3+ | CTA-2 |
| D3-14 | IaC security scanning NIST SSDFOWASP SAMM v2ISO 27001 | Infrastructure-as-code is scanned for misconfiguration. | T2 | L3+ | CTA-2 |
| D3-15 | Container vulnerability scanning NIST SSDFOWASP SAMM v2ISO 27001 | Images are scanned for known vulnerabilities pre-deploy. | T2 | L3+ | CTA-2 |
| D3-16 | API security testing NIST SSDFOWASP SAMM v2ISO 27001 | APIs are tested against authz, injection, and abuse cases. | T2 | L3+ | CTA-2 |
| D3-17 | Security regression testing NIST SSDFOWASP SAMM v2ISO 27001 | Fixed vulnerabilities are guarded by regression tests. | T2 | L3+ | CTA-2 |
| D3-18 | Penetration testing NIST SSDFOWASP SAMM v2ISO 27001 | Independent penetration tests validate real-world resilience. | T2 | L3+ | CTA-2 |
| D4-01 | Dependency inventory EU CRANIST SSDFSOC 2 | A complete, current inventory of all dependencies is maintained. | T3 | L2+ | CTA-1 |
| D4-02 | Automated CVE monitoring EU CRANIST SSDFSOC 2 | Dependencies are continuously monitored for new CVEs. | T2 | L2+ | CTA-1 |
| D4-03 | Dependency risk scoring EU CRANIST SSDFSOC 2 | Each dependency carries a quantified, tracked risk score. | T3 | L2+ | CTA-1 |
| D4-04 | Patch SLA enforcement EU CRANIST SSDFSOC 2 | Vulnerable dependencies are patched within defined SLAs. | T3 | L2+ | CTA-1 |
| D4-05 | Licence compliance EU CRANIST SSDFSOC 2 | Dependency licences are inventoried and policy-checked. | T3 | L2+ | CTA-1 |
| D4-06 | Transitive dependency analysis EU CRANIST SSDFSOC 2 | Indirect dependencies are resolved, mapped, and assessed. | T3 | L2+ | CTA-1 |
| D4-07 | Vendor / OSS assessment EU CRANIST SSDFSOC 2 | Suppliers and OSS projects are assessed for trustworthiness. | T3 | L2+ | CTA-1 |
| D4-08 | Supply chain attack detection EU CRANIST SSDFSOC 2 | Typosquatting and malicious-package signals are detected. | T2 | L2+ | CTA-1 |
| D4-09 | Automated dependency updates EU CRANIST SSDFSOC 2 | Safe dependency updates are automated and tested. | T2 | L2+ | CTA-1 |
| D4-10 | End-of-life tracking EU CRANIST SSDFSOC 2 | Unmaintained and EOL components are flagged and replaced. | T3 | L2+ | CTA-1 |
| D4-11 | Private registry control EU CRANIST SSDFSOC 2 | Internal artifacts flow through controlled private registries. | T3 | L2+ | CTA-1 |
| D4-12 | Dependency pinning EU CRANIST SSDFSOC 2 | Dependencies are pinned to verified, immutable versions. | T3 | L2+ | CTA-1 |
| D4-13 | SBOM-CVE correlation EU CRANIST SSDFSOC 2 | SBOMs are correlated against CVE feeds in real time. | T1 | L2+ | CTA-1 |
| D4-14 | Policy-as-code enforcement EU CRANIST SSDFSOC 2 | Dependency policy is enforced automatically as code. | T3 | L4+ | CTA-3 |
| D4-15 | Dependency vetting workflow EU CRANIST SSDFSOC 2 | New dependencies pass a documented vetting workflow. | T3 | L2+ | CTA-1 |
| D4-16 | Contractual SBOM obligations EU CRANIST SSDFSOC 2 | Suppliers are contractually required to provide SBOMs. | T1 | L2+ | CTA-1 |
| D5-01 | Runtime anomaly detection SOC 2ISO 27001PCI DSS | Anomalous runtime behaviour is detected and alerted. | T2 | L4+ | CTA-3 |
| D5-02 | Behavioral baseline SOC 2ISO 27001PCI DSS | Normal application behaviour is baselined for comparison. | T2 | L4+ | CTA-3 |
| D5-03 | Drift detection SOC 2ISO 27001PCI DSS | Deviation from expected configuration and behaviour is caught. | T2 | L4+ | CTA-3 |
| D5-04 | RASP protection SOC 2ISO 27001PCI DSS | Runtime application self-protection blocks live exploitation. | T2 | L4+ | CTA-3 |
| D5-05 | Application behavioral monitoring SOC 2ISO 27001PCI DSS | Application behaviour is monitored across production. | T2 | L4+ | CTA-3 |
| D5-06 | Kernel-level restrictions SOC 2ISO 27001PCI DSS | Workloads run under least-privilege kernel restrictions. | T3 | L4+ | CTA-3 |
| D5-07 | Audit logging & distributed tracing SOC 2ISO 27001PCI DSS | Actions are logged and traced end-to-end for forensics. | T2 | L4+ | CTA-3 |
| D5-08 | Runtime exploit detection SOC 2ISO 27001PCI DSS | Active exploitation attempts are detected at runtime. | T2 | L4+ | CTA-3 |
| D5-09 | Memory safety controls SOC 2ISO 27001PCI DSS | Memory-safety protections mitigate whole vulnerability classes. | T3 | L4+ | CTA-3 |
| D5-10 | Process behavior analytics SOC 2ISO 27001PCI DSS | Process activity is analysed for malicious patterns. | T2 | L4+ | CTA-3 |
| D5-11 | Runtime trust score updates SOC 2ISO 27001PCI DSS | Runtime signals continuously update the live Trust Score. | T2 | L5+ | CTA-4 |
| D5-12 | Cloud-native runtime controls SOC 2ISO 27001PCI DSS | Container and cloud-native runtime controls are enforced. | T3 | L5+ | CTA-4 |
| D6-01 | CTA Governance Charter ISO 27001DORANIS2 | A board-approved charter governs the code-trust programme. | T3 | L2+ | CTA-1 |
| D6-02 | Executive accountability ISO 27001DORANIS2 | A named executive owns code-trust outcomes and risk. | T3 | L2+ | CTA-1 |
| D6-03 | RACI matrix ISO 27001DORANIS2 | Responsibilities across trust controls are formally assigned. | T3 | L2+ | CTA-1 |
| D6-04 | Audit trail management ISO 27001DORANIS2 | Governance decisions and evidence are audit-logged and retained. | T3 | L2+ | CTA-1 |
| D6-05 | Compliance reporting ISO 27001DORANIS2 | Trust posture is reported to leadership and regulators. | T3 | L2+ | CTA-1 |
| D6-06 | Policy-as-code ISO 27001DORANIS2 | Governance policy is codified and enforced automatically. | T3 | L2+ | CTA-1 |
| D6-07 | Certification programme management ISO 27001DORANIS2 | Certification status and renewals are actively managed. | T3 | L2+ | CTA-1 |
| D6-08 | Third-party trust obligations ISO 27001DORANIS2 | Trust obligations extend contractually to third parties. | T3 | L2+ | CTA-1 |
| D6-09 | Regulatory compliance matrix ISO 27001DORANIS2 | Controls are mapped to applicable regulatory obligations. | T3 | L2+ | CTA-1 |
| D6-10 | Continuous improvement programme ISO 27001DORANIS2 | Findings feed a measured, continuous improvement loop. | T3 | L5+ | CTA-4 |
Five levels, applied per control
A maturity level is not an organisation-wide score — it characterises how well a specific capability is embedded. The same organisation may be L4 on one control and L1 on another.
No documented process. The control is absent, informal, or exists only as individual knowledge. No named owner. Evidence is anecdotal. Risk is unmanaged.
A process exists but is inconsistently applied. Manually executed and individual-dependent. Basic evidence exists but is not structured or regularly captured.
Standardised, documented, and consistently applied across the organisation. Named owner. Structured evidence retained. The minimum regulatory baseline for most obligations.
KPI-driven with continuous measurement. Performance tracked and reported. Exceptions formally managed with time-bounded resolution. System-generated evidence.
Fully automated, self-healing, and continuously evidenced. Independently assured by third-party attestation. Self-improving from measured outcomes and threat intelligence.
From maturity ratings to one Trust Score
Each control is scored across five axes, aggregated into weighted domain scores, then composed into a single executive-readable Trust Score.
The five scoring axes
How the Trust Score is built
- 1 · Each applicable control is rated L1–L5 (1–5 points).
- 2 · A domain score is the weighted average of its control scores.
- 3 · The Trust Score sums each domain score × its domain weight.
- 4 · 7 hard gates must pass before any CTA level is awarded.
Hard gates address foundational security requirements that cannot be compensated for by high scores elsewhere — no amount of maturity in one domain can buy a certification level if a gate fails.
Not all evidence is equal
Assessment is evidence-first. Cryptographic proof outranks documentation, which outranks assertion — and higher maturity levels require higher-tier evidence.
Cryptographic evidence
The strongest, machine-verifiable proof.
Signatures, attestations, hashes, transparency-log entries, SBOMs, provenance records.
System-generated artefacts
Automated output from tooling and pipelines.
CI/CD logs, automated scan reports, pipeline execution records, monitoring dashboards.
Structured documentation
Maintained records and process artefacts.
Policies, standards, process documents, architecture diagrams, manual records.
Management attestation
The weakest tier — assertions only.
Interview responses, declarations, and unverified assertions.
One assessment, many obligations
NS-CTAF maps to the standards and regulations that shape software security worldwide.
SLSA
FrameworkSupply-chain Levels for Software Artifacts — build integrity levels.
NIST SSDF (SP 800-218)
FrameworkSecure Software Development Framework practices.
OWASP SAMM v2
FrameworkSoftware Assurance Maturity Model.
in-toto
FrameworkSupply-chain step attestation framework.
EU Cyber Resilience Act
RegulationEU product cybersecurity and SBOM obligations.
DORA
RegulationDigital Operational Resilience Act for EU financial entities.
NIS2
RegulationEU network & information security directive.
US EO 14028
RegulationExecutive Order on improving the nation’s cybersecurity.
ISO/IEC 27001:2022
StandardInformation security management systems.
SOC 2
StandardTrust services criteria for service organisations.
PCI DSS v4.0.1
StandardPayment card industry data security standard.
Turn software assurance into an external trust signal.
Fixed fee $5,000 USD · ~20 business days · Final report, CTA certificate, and improvement roadmap.