Nucleus Systems
About the Framework

Created by Nucleus Systems

The Nucleus Systems Code Trust Assurance Framework (NS-CTAF) is a public trust infrastructure for the software economy — defining trust, measuring trust, certifying trust, and making trust visible to the market.

Who created the Framework

A framework built on assurance work

NS-CTAF was created by Nucleus Systems (Pty) Ltd as part of its work in software assurance, code security, secure delivery, supply-chain risk, and evidence-based maturity measurement. It is positioned as a new category — Code Trust Assurance Intelligence — because it measures trust, evidence, maturity, certification, and continuous assurance rather than simply finding issues.

The initiative is deliberately launched as a serious market trust infrastructure, not a consulting brochure. Independence, methodological rigour, transparency, and commercial usefulness are the design goals.

Methodological rigour

Evidence-first scoring, hard gates, and independent review before certification.

Independence

Assessor ethics, conflict-of-interest, and quality-assurance policies.

Ecosystem

Independent advisors, accredited assessors, and partners as adoption grows.

Transparency

Published methodology, status rules, and versioned release notes.

Credibility safeguards

How the Framework stays trustworthy

A framework that certifies trust must itself be governed transparently. These safeguards keep NS-CTAF credible as it scales.

Certification methodology published at a high level
Certificate status rules and verification process published
Appeals, suspension, and withdrawal policy
Assessor independence and conflict-of-interest policy
Independent advisory board as adoption grows
Versioned framework with published release notes
Sensitive technical evidence kept private; external assurance reports allowed
Positioning

What NS-CTAF is — and what it deliberately is not

The category matters. A scanner tells you what is broken in the code you already have. NS-CTAF tells you, with evidence, whether the system that produces that code can be trusted at all.

It is

  • A measurement model — 86 controls, six weighted domains, five maturity levels, five scoring axes.
  • An evidence standard — what counts as proof, and how much weight each kind of proof carries.
  • A certification scheme — CTA-1 to CTA-4, awarded against published thresholds and hard gates.
  • A public trust signal — a registry entry a customer, regulator, or insurer can verify independently.

It is not

  • A scanner, or a replacement for one — scanner output is an input to the assessment, not the assessment.
  • A questionnaire — self-asserted answers without evidence cannot clear the cryptographic gates.
  • A one-off audit — a control that only functions on audit day cannot reach high maturity.
  • A consulting engagement dressed as a standard — the methodology, thresholds, and status rules are published.
Design principles

The decisions the model is built on

Each principle exists because of a specific failure mode seen in real supply chain compromises. They are what make a score hard to argue with.

01

Cryptography-first

Cryptographic evidence, signatures, attestations, and hashes back every trust claim. Policy assertions without cryptographic proof cannot achieve high maturity.

Why: Trust claims without cryptographic backing are unverifiable. In supply chain attacks, signed versus unsigned is the difference between evidence and assumption.

02

Continuous over point-in-time

Trust is measured continuously. Controls that only function on audit day cannot achieve high maturity scores.

Why: SolarWinds persisted for months because monitoring was periodic. Continuous signals eliminate the gap attackers exploit.

03

Lifecycle-wide coverage

Trust is demonstrated from developer identity through to runtime behaviour. Partial lifecycle coverage creates exploitable gaps.

Why: Supply chain attacks target the weakest link. A framework covering build integrity but not runtime gives false assurance in production.

04

Evidence-graded maturity

Maturity levels require progressively higher-quality evidence, from informal (L1) to continuous cryptographic (L5).

Why: Evidence quality separates genuine trust from documented intention. High standards prevent compliance theatre.

05

AI-native architecture

Controls explicitly address AI-generated code and AI coding tools. AI is a first-class trust dimension, not an afterthought.

Why: AI code volume is growing exponentially. Frameworks predating AI tools are structurally unable to address trust in AI-generated software.

06

Automation-ready design

Each control defines an automation pathway from manual (L2–L3) to continuously automated (L4–L5).

Why: Manual processes cannot scale with AI-driven code growth. Automation pathways keep Nucleus Systems Code Trust Assurance Framework relevant at modern code velocity.

07

Regulation-anchored

Every control maps to specific articles of applicable regulations. Controls without a regulatory basis are not included.

Why: Organisations need legally defensible evidence. Regulatory anchoring makes assessment outputs auditor-ready.

Defensibility

Why a score survives being challenged

A trust score is only useful if it holds up when a customer, an auditor, or an acquirer pushes back on it. Four structural choices make that possible.

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.

At a glance

The published specification

Everything below is fixed and published, so an assessment can be reproduced and a score can be checked.

Framework name
Nucleus Systems Code Trust Assurance Framework & Maturity Measurement Model, v1.0
Edition
Professional Edition v1.0 — 2026
Controls
86 controls, fully defined with requirements, guidance, and framework alignment
Domains
6 domains, weighted by trust significance and supply-chain risk impact
Domain weights
D1 Identity 18% · D2 Integrity 18% · D3 Secure Dev 22% · D4 Supply Chain 20% · D5 Runtime 14% · D6 Governance 8%
Maturity scale
L1 Initial → L2 Developing → L3 Defined → L4 Managed → L5 Optimised
Maturity interpretations
430 control-specific level interpretations (5 levels × 86 controls)
Framework alignment
NIST SSDF · SLSA · in-toto · Sigstore · OWASP SAMM · BSIMM · ISO/IEC 27001 · EU CRA · EO 14028 · NIS2 · DORA · PCI DSS v4.0.1 — 30+ in total
Certification
CTA-1 Transparent → CTA-2 Verified → CTA-3 Assured → CTA-4 Adaptive Trust
Training
Role-specific pathways: Developer · Security Engineer · Security Champion · Architect · Board

“Code trust is no longer a claim; it is evidence.”

Nucleus Systems (Pty) Ltd · Nucleus Systems Code Trust Assurance Framework v1.0

Turn software assurance into an external trust signal.

Fixed fee $15,000 USD · ~20 business days · Final report, CTA certificate, and improvement roadmap.