Secure Software Supply Chain and Release Integrity

Draft 0.1 — 2 August 2026
Security controls reduce risk; they do not prove that software is vulnerability-free. Verification claims must name the artifact, control, version, time, and limitations.

Objective

ANUKA software will include public specifications, browser extensions, site scripts, APIs, MCP servers, SDKs, CLI tools, schemas, skills, and resident-product adapters.

A compromise in any one package can cross product and trust boundaries.

The rule is:

Every released artifact must be traceable from reviewed source to reproducible evidence about how it was built, tested, and published.

Baselines

The secure-development baseline should use:

NIST Secure Software Development Framework 1.1 as the current final baseline;
NIST SSDF 1.2 draft as tracked, not final, guidance;
NIST SP 800-218A for generative-AI and dual-use model development where relevant;
SPDX 3.0 for software bill-of-materials and related supply-chain metadata where supported;
Semantic Versioning for public software contracts;
ecosystem-native signing and provenance tools selected by ADR.

Asset classes

Security requirements apply to:

source repositories;
documentation and schemas;
build workflows;
dependencies;
container images;
browser-extension packages;
JavaScript bundles and CDN assets;
SDK packages;
CLI binaries;
MCP servers;
skill packages;
infrastructure definitions;
database migrations;
model and prompt assets;
release metadata.

Repository controls

Production repositories should require:

protected default branch;
pull requests;
required reviews;
CODEOWNERS for sensitive paths;
passing CI;
signed or attributable commits where policy requires;
secret scanning;
dependency scanning;
branch deletion after merge;
restricted force push;
audit log access;
least-privilege automation tokens.

Administrative bypasses must be rare, logged, and reviewed.

Sensitive paths

Examples requiring specialized review:

.github/workflows/
infrastructure/
schemas/
security/
authorization/
payments/
extensions/
mcp/
skills/
database/migrations/

A generated file may require review of its source and generation workflow rather than manual line-by-line approval.

Secure development lifecycle

Each material change should address:

security and privacy requirements;
threat model or abuse case;
implementation review;
automated testing;
dependency and secret checks;
artifact build;
provenance and SBOM;
release approval;
deployment validation;
vulnerability monitoring and response.

The depth is proportional to risk.

Threat modeling

Threat models cover:

assets;
actors and trust boundaries;
entry points;
abuse cases;
data flows;
authorization;
secrets;
dependencies;
update mechanisms;
recovery;
residual risk.

Agent-specific threats include prompt injection, tool substitution, confused deputy behavior, data exfiltration, poisoned skills, and delegated-authority escalation.

Dependency policy

Dependencies must have:

known source;
license review;
maintained version;
integrity lock;
vulnerability monitoring;
transitive dependency visibility;
owner;
replacement or containment plan for critical packages.

Avoid dependencies for trivial functionality when they materially enlarge the attack surface.

Lockfiles

Released builds should use committed lockfiles or equivalent reproducible resolution.

The lockfile must be generated by an approved toolchain and reviewed for unexpected source, version, or integrity changes.

A lockfile does not replace an SBOM or vulnerability review.

Software bill of materials

Release artifacts should produce an SBOM where practical.

The SBOM identifies:

artifact;
components;
versions;
package identifiers;
relationships;
licenses;
suppliers or origins;
hashes;
generation tool and version.

SPDX 3.0 is the preferred cross-ecosystem baseline candidate.

SBOM publication level depends on security and contractual considerations, but internal availability is required for critical services.

Build isolation

Builds should run in isolated, ephemeral environments with:

pinned actions and toolchains;
minimal network access;
least-privilege credentials;
no developer workstation secrets;
clean source checkout;
deterministic inputs;
controlled caches;
artifact digest generation;
log retention.

Build systems must not have unrestricted production access.

CI workflow security

Workflow changes are privileged code changes.

Controls include:

pin third-party actions by immutable digest or reviewed version policy;
limit workflow permissions;
separate untrusted pull-request execution from secrets;
protect release environments;
require approval for production deployment;
avoid shell interpolation of untrusted input;
review reusable workflow callers;
rotate compromised tokens.

Provenance

Build provenance should connect:

artifact digest;
source repository and commit;
build workflow;
builder identity;
build parameters;
dependency or material references;
time;
release channel.

Provenance proves declared build facts, not source-code correctness.

Artifact signing

Signing policies may cover:

container images;
CLI binaries;
browser extensions;
SDK packages;
schema bundles;
skill packages;
release manifests.

Verification must check:

signer or trusted identity;
artifact digest;
signature validity;
certificate or key status;
trusted workflow or environment;
release policy.

A valid signature from an unauthorized signer is not a valid release.

Key management

Signing and release keys require:

named owner;
hardware-backed or managed protection where appropriate;
least privilege;
rotation;
recovery;
revocation;
separation from developer credentials;
audit records;
incident procedure.

Shared private keys in repository secrets should be avoided when identity-based short-lived signing is available and reviewed.

Release manifest

Every release should publish a machine-readable manifest containing:

product or package;
version;
source commit;
artifact digest;
build provenance reference;
SBOM reference;
schemas and protocol versions;
dependency lock digest;
test summary;
signer;
release channel;
publication time;
known limitations.

Browser extensions

Extension security requirements include:

Manifest V3-compatible architecture where required;
no remotely hosted executable code;
minimal permissions;
activeTab-first behavior for general browsing access;
CSP-compatible bundle;
review of content-script/page boundaries;
safe messaging and origin validation;
secure update through browser stores or reviewed enterprise channels;
reproducible source-to-package mapping where practical.

Store approval is distribution review, not proof of ANUKA security.

Site SDK and CDN assets

Remote site assets require:

HTTPS;
versioned immutable URLs;
content hashes;
rollback;
CSP documentation;
Subresource Integrity for pinned assets where compatible with deployment model;
controlled loader behavior;
no silent expansion of data collection;
kill switch.

A mutable latest.js may be offered for convenience only with clear risk and release policy. High-assurance integrations should pin versions.

SDK packages

SDK release controls include:

package namespace ownership;
multi-factor authentication;
provenance where the registry supports it;
no manual local publishing for stable releases;
generated-code verification;
dependency review;
changelog;
deprecation metadata;
package-name typosquatting monitoring.

MCP servers and tools

MCP releases require:

server operator verification;
pinned protocol revision;
tool schema review;
capability mapping;
authorization tests;
prompt-injection and confused-deputy tests;
artifact provenance;
dependency and container scanning;
network egress policy;
scoped provider credentials.

Tool definitions are part of the security boundary.

Skill packages

Skill releases require:

manifest and skill.md consistency;
tool dependency pinning;
capability ceiling;
injection scenarios;
approval tests;
secret scanning;
source and artifact digest;
maintainer verification;
visible trust level.

A skill must not fetch mutable remote instructions and treat them as part of a verified release.

Secrets management

Secrets must not appear in:

source;
documentation examples;
issue comments;
CI logs;
telemetry;
model prompts;
skill packages;
browser local storage without a reviewed protection model.

Use managed secret storage, short-lived credentials, workload identity, and rotation.

Secret detection

Scanning should run:

pre-commit where practical;
on pull requests;
on default branch;
across release artifacts;
periodically across history.

A detected exposed secret is treated as compromised even if quickly deleted from the repository.

Vulnerability management

The vulnerability process includes:

intake channel;
triage;
severity and exploitability;
affected versions;
containment;
fix and test;
release;
notification;
credit and disclosure;
retrospective and root-cause prevention.

Public repositories should include SECURITY.md with supported versions and reporting instructions.

Coordinated disclosure

Security reports should have a private path.

The response policy declares:

acknowledgment target;
scope;
safe-harbor language where approved;
encrypted communication option;
disclosure coordination;
reward program status if any;
public advisory policy.

Do not require a reporter to publish sensitive exploit details in a public issue.

Severity

Severity considers:

confidentiality;
integrity;
availability;
authorization bypass;
financial impact;
privacy harm;
cross-tenant reach;
exploitability;
required privileges;
user interaction;
detectability;
agent amplification.

A common scoring system may inform but not replace contextual assessment.

Patch policy

A security release declares:

affected versions;
fixed versions;
workarounds;
exploit status where safe;
upgrade urgency;
compatibility impact;
artifact digests;
advisory identifier.

Emergency fixes may use accelerated review but still require audit evidence and retrospective review.

Dependency vulnerabilities

Not every advisory creates equal risk.

Triage considers:

whether the vulnerable code path is reachable;
runtime and configuration;
data exposure;
network access;
compensating controls;
exploit maturity;
package maintenance.

Suppression requires an owner, rationale, expiry, and re-evaluation trigger.

Malicious packages

Controls should detect:

package-name confusion;
unexpected maintainer change;
install scripts;
new binary blobs;
dependency source changes;
obfuscated code;
sudden permission expansion;
compromised registry account.

High-risk dependencies may be mirrored or vendored under a reviewed policy.

Container security

Container images should:

use minimal base images;
pin base digest;
run as non-root where possible;
avoid embedded secrets;
expose only required ports;
use read-only filesystems where practical;
include health behavior;
receive vulnerability scanning;
be signed and provenance-linked.

Infrastructure as code

Infrastructure changes follow code review and policy checks.

Controls include:

least privilege;
encrypted storage;
network boundaries;
logging;
backup;
deletion protection for critical state;
environment separation;
drift detection;
plan review before apply.

Cloud-console emergency changes must be recorded and reconciled back into code.

Database migrations

Migration packages require:

version and checksum;
forward and recovery plan;
backup assessment;
lock and downtime analysis;
privacy and retention review;
test against representative data;
owner and approval;
post-migration verification.

Destructive migrations need explicit evidence that required retention and export obligations are satisfied.

AI model and prompt assets

When ANUKA trains, fine-tunes, or distributes model assets, SP 800-218A should supplement the general SSDF.

Track:

data provenance and rights;
model source and license;
training configuration;
evaluations;
safety and security tests;
artifact digest;
deployment constraints;
known limitations;
update and rollback.

Provider-hosted models still require configuration and dependency records.

Release approval classes

S0 — Documentation-only

Automated checks and normal review.

S1 — Standard software

Tests, dependency scan, provenance, owner approval.

S2 — Sensitive capability

Additional security review for identity, authorization, consent, reputation, payments, or agent tools.

S3 — Critical release

Independent review, staged rollout, recovery test, incident readiness, and explicit authorized approval.

Risk class is based on effect, not repository popularity.

Conformance and evidence

A release may assert:

source reviewed;
tests passed;
SBOM generated;
artifact signed;
provenance verified;
known-vulnerability policy passed;
conformance suite passed.

Claims must reference the exact artifact and evidence.

Do not label a product “secure” solely because these checks passed.

Retention

Security evidence retention covers:

release manifests;
provenance;
SBOM;
test summaries;
approvals;
vulnerability decisions;
signatures and status;
incident references.

Retention balances audit, legal, privacy, and operational needs.

Third-party services

Provider diligence should examine:

security documentation;
identity and access controls;
audit logs;
data handling;
incident notice;
subcontractors;
export and deletion;
business continuity;
vulnerability response;
contractual responsibilities.

A compliance report is evidence, not a substitute for architecture review.

MVP release gates

Before stable production releases:

default branches are protected;
CI permissions are minimal;
secrets scanning is active;
dependency lockfiles exist;
critical artifacts produce SBOMs;
builds are isolated and reproducible enough to investigate;
release artifacts have digests and provenance;
supported versions and reporting path are published;
browser extensions contain no remote executable code;
MCP tools pass authorization and injection tests;
skills pass manifest, secret, and approval tests;
backups and rollback are verified;
emergency release procedure exists.

Acceptance criteria

secure development follows a named baseline;
final and draft NIST baselines are distinguished;
repositories protect sensitive paths;
dependencies are locked and monitored;
releases produce SBOM, digest, and provenance where required;
signing identity and policy are verified;
secrets are short-lived and never embedded;
extension and site assets have controlled update paths;
vulnerability reporting is private and documented;
suppressions expire;
infrastructure and migrations are reviewed;
model and prompt assets have provenance;
release evidence supports precise, not exaggerated, claims.

Sources

Verification record

Sources opened and checked: 2 August 2026
Final SSDF baseline: 1.1
SSDF 1.2 status: Initial Public Draft, not baseline
SPDX current version observed: 3.0
Signing and provenance implementation: ADR required