A measurable architecture for software trust
The Nucleus Systems Code Trust Assurance Framework (NS-CTAF) measures whether software can be trusted across its full lifecycle — from developer identity and code integrity to secure development, dependencies, runtime behaviour, and governance accountability.
Not a checklist. Not a scan.
The Nucleus Systems Code Trust Assurance Framework & Maturity Measurement Model v1.0 is a continuous, cryptographically verifiable, and measurable standard for software code trust — spanning identity, integrity, secure development, supply chain, runtime assurance, and governance.
It introduces Code Trust Assurance (CTA) as a distinct discipline: the practice of establishing, measuring, and continuously maintaining evidence-based trust in software across identity, integrity, secure development, supply chain, runtime behaviour, and governance.
With 86 controls across six weighted domains, a five-axis scoring model, alignment to over 30 global frameworks, and a four-level certification programme, it replaces fragmented, tool-centric checklists with a single instrument for measuring and improving software trust.
Every input is a trust decision
Modern software is assembled from internal code, open-source components, build tools, CI/CD pipelines, containers, cloud services, APIs, and increasingly AI-generated code. NS-CTAF exists because most organisations cannot prove, continuously and with evidence, that those trust decisions are controlled.
Software supply chain attacks increasingly exploit trusted identities, components, and pipelines.
SBOM and dependency visibility are becoming procurement and regulatory expectations.
AI-generated code introduces new attribution, review, and trust-classification challenges.
Customers, regulators, investors, and acquirers increasingly need evidence-backed assurance.
Five questions. For most organisations, the honest answer to all five is no.
These are not questions a vulnerability scanner was ever designed to answer. They are the questions a regulator, an acquirer, or an enterprise customer will eventually ask you.
Can you cryptographically prove that the developer who committed code to your production branch is who they claim to be?
Typical answer · NoCan you demonstrate that your build pipeline was not modified between the last security audit and today's release?
Typical answer · NoDo you have independently verifiable build provenance attestations a downstream consumer could verify without trusting your assertions?
Typical answer · NoIs every dependency in your production software pinned to a cryptographically verified version?
Typical answer · NoWhen a runtime anomaly occurs in production, can you trace it to a specific code change, in a specific commit, by a specific verified contributor?
Typical answer · NoThis is not a gap that adding another scanner closes. It is an architecture gap — and it needs a control architecture, a maturity model, and a certification programme that turn scanning activity into demonstrable, independently verifiable software trust.
Scanning tells you what you found. It cannot tell you what you can trust.
Most organisations can say how many vulnerabilities their scanner found last quarter. Almost none can cryptographically prove who wrote their code, that their build pipeline was not compromised, or that the dependencies they shipped were not substituted in transit.
- Are your commits signed?
- Do you run security scans?
- Do you have a policy?
Binary questions that validate intent. Software trust is not binary — it exists on a spectrum and must be measured, validated, and proven over time.
- · How consistently are commits signed across your entire organisation — not just a few repositories?
- · What percentage of your codebase is truly covered by enforced controls?
- · How are signing keys generated, stored, rotated, and revoked?
- · Are these controls operating continuously, or only when someone checks?
- · Where is the verifiable evidence that proves all of this is working over time?
What it evaluates
- Consistency of implementation
- Depth of coverage
- Operational reliability over time
- Quality of evidence, especially cryptographic proof
- Level of automation and resilience
Once trust is measurable, it becomes
- Actionable — with clear, prioritised improvement pathways
- Comparable — across teams, systems, and organisations
- Defensible — under audit, regulatory scrutiny, and due diligence
- Scalable — through automation and continuous assurance
You are probably assessing the same control three times over
A control addressing build provenance might be independently assessed for SLSA Level 3, NIST SSDF RV.1, and Executive Order 14028 Section 4 — three assessments of fundamentally the same trust capability, with three evidence collections, three gap analyses, and three reporting formats.
lost to duplicate evidence collection across overlapping frameworks.
per material framework update, for gap analysis and control mapping.
instead of one defensible truth about your code trust posture.
| Framework | Role in the trust puzzle | Core obligations | Enforcement |
|---|---|---|---|
| SLSA | Build integrity — the what of artifact provenance | L1 documentation, L2 signed provenance, L3 hardened build platform, L4 reproducible builds with independent verification. | Market-driven: increasingly required by enterprise procurement and referenced in US CISA guidance. |
| NIST SSDF SP 800-218 | Development process — the how of secure development | Prepare, Protect, Produce and Respond practices, with specific tasks and examples for each function. | Mandatory for US federal software suppliers; referenced in Executive Order 14028 attestation and FedRAMP. |
| OWASP SAMM v2.0 | Development maturity — the measure of programme quality | 5 business functions, 15 security practices, 3 maturity levels per practice across governance to operations. | De facto standard for measuring software security programmes; referenced in PCI DSS Req. 6 and ISO/IEC 27001. |
| EU Cyber Resilience Act | Product security law — the legal obligation in the EU | Article 13 SBOM, Article 14 vulnerability handling with notification timelines, Article 18 supply chain security. | Binding law. Fines up to €15 million or 2.5% of global annual turnover. |
Fragmentation is not only an efficiency problem. It is a risk management problem and a board communication problem at the same time. One assessment, mapped to all of them, produces one defensible answer instead of seven inconsistent ones.
Four attacks that conventional scanning could not have stopped
Each shares a structural pattern: trust was assumed where it should have been verified. The compromise occurred exactly where cryptographic verification was absent.
Build pipeline integrity — malicious code injected into a signed release.
Tamper-evident pipeline design, build provenance attestation, artifact signing, in-toto attestations.
Transitive dependency visibility — organisations could not identify affected systems.
Dependency inventory management, transitive dependency analysis, SBOM-CVE correlation, dependency risk scoring.
Contributor identity trust — a maintainer account compromised over a two-year timeline.
Developer identity verification, contributor trust weighting, third-party identity vetting, trust lineage graph.
Domain hijack — a legitimate CDN domain acquired and used to serve malicious code.
Supply chain attack detection, private registry controls, component origin verification.
Built so that documentation cannot outscore reality
There is a well-known observation among assessors: the fastest way to improve a code security score is to hire someone skilled in documentation rather than in security engineering. This framework is designed to make that impossible.
The cryptographic evidence gate
For identity and integrity controls, the absence of cryptographic evidence caps the score at L2 — no matter how well written the policy is. A policy requiring signed commits, without evidence that enforcement actually functioned over the last three months, cannot score above L2.
Coverage and operation carry half the score
Implementation Coverage and Operating Effectiveness together account for 50% of every control score, because the most reliable predictor of genuine trust is consistent, verifiable operation across the full scope of in-scope systems.
Weighting follows real risk
Secure Development carries the highest weight at 22% because upstream prevention has multiplicative downstream effects. Dependency and Supply Chain carries 20% because the average enterprise application is 70–80% open-source components, and every unverified dependency is an attack vector.
Seven hard gates that cannot be papered over
Absolute ceilings that limit attainable maturity regardless of the composite calculation, because certain conditions make it structurally impossible for a control to be genuinely mature.
of identified gaps remain unaddressed six months after a typical supply chain security assessment.
Most assessments are built to measure, not to manage
This is not a failure of intent — it is a failure of design. Most code security assessments are built to measure, not to manage. They produce findings but not the operational infrastructure through which gaps are closed, tracked, and continuously verified.
Assessment output becomes board-ready trust reporting, a prioritised improvement roadmap, certification readiness indicators, and longitudinal maturity tracking — management intelligence as a natural output of operations rather than a separate reporting effort.
Structural responses to real failure modes
These are not theoretical ideals. Each principle answers a failure mode observed in a real supply chain attack.
Cryptography-first
Cryptographic evidence, signatures, attestations, and hashes back every trust claim. Policy assertions without cryptographic proof cannot achieve high maturity.
Why it matters — Trust claims without cryptographic backing are unverifiable. In supply chain attacks, signed versus unsigned is the difference between evidence and assumption.
Continuous over point-in-time
Trust is measured continuously. Controls that only function on audit day cannot achieve high maturity scores.
Why it matters — SolarWinds persisted for months because monitoring was periodic. Continuous signals eliminate the gap attackers exploit.
Lifecycle-wide coverage
Trust is demonstrated from developer identity through to runtime behaviour. Partial lifecycle coverage creates exploitable gaps.
Why it matters — Supply chain attacks target the weakest link. A framework covering build integrity but not runtime gives false assurance in production.
Evidence-graded maturity
Maturity levels require progressively higher-quality evidence, from informal (L1) to continuous cryptographic (L5).
Why it matters — Evidence quality separates genuine trust from documented intention. High standards prevent compliance theatre.
AI-native architecture
Controls explicitly address AI-generated code and AI coding tools. AI is a first-class trust dimension, not an afterthought.
Why it matters — AI code volume is growing exponentially. Frameworks predating AI tools are structurally unable to address trust in AI-generated software.
Automation-ready design
Each control defines an automation pathway from manual (L2–L3) to continuously automated (L4–L5).
Why it matters — Manual processes cannot scale with AI-driven code growth. Automation pathways keep Nucleus Systems Code Trust Assurance Framework relevant at modern code velocity.
Regulation-anchored
Every control maps to specific articles of applicable regulations. Controls without a regulatory basis are not included.
Why it matters — Organisations need legally defensible evidence. Regulatory anchoring makes assessment outputs auditor-ready.
Software supply chain security is no longer voluntary
Three regulations now impose mandatory obligations on the organisations that build and supply software. Every NS-CTAF control maps to specific articles, so assessment output is auditor-ready.
EU Cyber Resilience Act
In force since December 2024
Article 13 mandates SBOM provision, Article 14 vulnerability handling with defined notification timelines, and Article 18 supply chain security for integrated components. Fines reach €15 million or 2.5% of global annual turnover.
US Executive Order 14028
Signed May 2021, implemented 2022–2024
Suppliers to the US federal government must attest to their software development practices, provide SBOMs for all delivered software, and demonstrate compliance with NIST SSDF SP 800-218.
DORA
Effective January 2025
Articles 28–30 require EU financial entities and their ICT providers to implement contractual security obligations, conduct supply chain risk assessments, and evidence third-party risk management.
Six domains of software trust
NS-CTAF structures trust into six weighted domains, each an independently assessable dimension of the software supply chain.
Identity & Provenance
Who wrote the code, and where it came from.
Integrity & Immutability
Whether builds and artifacts are tamper-proof.
Secure Development Practices
Whether secure engineering stops vulnerabilities at the source.
Dependency & Supply Chain
Whether third-party components are governed and controlled.
Runtime Behavior Assurance
Whether deployed software keeps behaving as expected.
Governance & Accountability
Whether ownership and policy sustain trust over time.
Built by Nucleus Systems
NS-CTAF was created by Nucleus Systems as part of its work in software assurance, code security, secure delivery, supply-chain risk, and evidence-based maturity measurement.
The framework
The NS-CTAF model itself — 86 controls, six domains, and the Trust Score methodology.
The assessment
A fixed-fee, evidence-first engagement that independently scores your posture.
The certification
A public CTA-1 to CTA-4 signal, listed in the Trust Registry and independently verifiable.
As adoption grows, Nucleus Systems is introducing independent advisors, accredited assessors, and a partner ecosystem to sustain the framework’s independence and rigour.
Who NS-CTAF helps
From software vendors to regulators, NS-CTAF turns software trust into something measurable and comparable.
Security tools find issues. Nucleus Systems Code Trust Assurance Framework proves trust.
Fixed fee $15,000 USD · ~20 business days · Final report, CTA certificate, and improvement roadmap.