Pillar — Security & Access Control

Prefix: SEC- Catalog: v1.1 deltas (additive to v1.0 Security & Access Control). What it measures: whether the controls that keep an agent from leaking secrets, shipping a vulnerable dependency, or bypassing review still hold when the subject is a product portfolio — one scan, one lockfile, and one protected main are not enough.

v1.0 already covers committed-secret hygiene, ignored env files, a dependency audit gate, CODEOWNERS, branch protection, contribution provenance, automated dependency updates, security headers, and an SBOM on release. These v1.1 criteria add the portfolio-scale attribution and identity an agent needs once it is changing more than one application in the same product.

Criteria in this pillar

SEC-100 — Secret findings attributed to an application

Level: 3 · Scope: portfolio · Check: deterministic
Secret scanning (SEC-010) attributes each finding to an application path (or published package). A repository-wide scan that emits an unscoped list does not satisfy this criterion. Path exclusions are committed and reviewed.
Rationale: a two-hundred-finding dump is not a work item an agent can pick up. Slice attribution is how a portfolio remediates without boiling the ocean, and how a new leak is routed to the owners of that tree.
Evidence expected: scan config with a path-to-application map; a sample report includes application identifiers; exclusion list is committed; CI fails on unattributed findings outside that list.

SEC-110 — Dependency audit per application

Level: 3 · Scope: portfolio · Check: deterministic
Each application and published package runs a production-dependency audit (SEC-030) against its own lockfile. A root-only audit that misses nested manifests does not satisfy this criterion. HIGH or CRITICAL findings still fail the job.
Rationale: agents add dependencies in the slice they touch. A single root audit of one lockfile leaves every other application unguarded and teaches the agent that "the audit already ran".
Evidence expected: a CI matrix or path filter that audits each lockfile; failure on HIGH or CRITICAL; a newly added application cannot ship without the gate.

SEC-120 — Every production-shipping ref is protected

Level: 3 · Scope: portfolio · Check: manual
Every ref that can ship production (the default branch, per-application deploy pointers, or equivalent) requires pull-request review, passing required checks, and no force-push (SEC-050). Protecting only main while other production-shipping refs are writable does not satisfy this criterion.
Rationale: portfolio deploys often use per-application refs. An agent with write access to an unprotected deploy pointer bypasses the review bar on main and lands unreviewed code in production.
Evidence expected: protection rules (or documented equivalent) on each production-shipping ref; the list of those refs matches the published deploy topology; force-push is denied; documentation names the refs.

SEC-130 — CODEOWNERS cover every application path

Level: 3 · Scope: portfolio · Check: deterministic
CODEOWNERS (SEC-040) assigns at least one owner to every application directory and every published package. A root catch-all with no per-application lines does not satisfy this criterion unless the portfolio has exactly one application.
Rationale: a single global owner is a bottleneck and a lie about who reviews a slice. Agents need the owning reviewer for the tree they changed, not a default that rubber-stamps every path.
Evidence expected: CODEOWNERS (or equivalent) with a rule per application path; CI or a lint fails an application added without an owner; syntax valid.

SEC-140 — CI and deploy use short-lived identity

Level: 4 · Scope: portfolio · Check: deterministic
Continuous integration and production deploy authenticate to cloud and forge APIs with short-lived workload identity (OIDC or equivalent). Long-lived access keys stored as repository secrets for those paths fail this criterion. Exceptions are enumerated, owned, and time-bounded.
Rationale: a leaked static cloud key is an organization-wide incident. Agents that copy "the secret the last workflow used" will mint more of them unless the platform refuses. Secret-free compile (BLD-110) does not cover how the deploy itself authenticates.
Evidence expected: workflow or deploy config using OIDC or workload identity; absence of static cloud access keys for those jobs, or a dated exception list; a documented identity per application or shared deployer.

v1.0 Security & Access Control — the published SEC-010 through SEC-090 criteria.
v1.1 pillars — draft catalog, including these deltas and the six new pillar stubs.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 3 · Scope: portfolio · Check: deterministic

Secret scanning (SEC-010) attributes each finding to an application path (or published package). A repository-wide scan that emits an unscoped list does not satisfy this criterion. Path exclusions are committed and reviewed.

Rationale: a two-hundred-finding dump is not a work item an agent can pick up. Slice attribution is how a portfolio remediates without boiling the ocean, and how a new leak is routed to the owners of that tree.

Evidence expected: scan config with a path-to-application map; a sample report includes application identifiers; exclusion list is committed; CI fails on unattributed findings outside that list.

Level: 3 · Scope: portfolio · Check: deterministic

Each application and published package runs a production-dependency audit (SEC-030) against its own lockfile. A root-only audit that misses nested manifests does not satisfy this criterion. HIGH or CRITICAL findings still fail the job.

Rationale: agents add dependencies in the slice they touch. A single root audit of one lockfile leaves every other application unguarded and teaches the agent that "the audit already ran".

Evidence expected: a CI matrix or path filter that audits each lockfile; failure on HIGH or CRITICAL; a newly added application cannot ship without the gate.

Level: 3 · Scope: portfolio · Check: manual

Every ref that can ship production (the default branch, per-application deploy pointers, or equivalent) requires pull-request review, passing required checks, and no force-push (SEC-050). Protecting only main while other production-shipping refs are writable does not satisfy this criterion.

Rationale: portfolio deploys often use per-application refs. An agent with write access to an unprotected deploy pointer bypasses the review bar on main and lands unreviewed code in production.

Evidence expected: protection rules (or documented equivalent) on each production-shipping ref; the list of those refs matches the published deploy topology; force-push is denied; documentation names the refs.

Level: 3 · Scope: portfolio · Check: deterministic

CODEOWNERS (SEC-040) assigns at least one owner to every application directory and every published package. A root catch-all with no per-application lines does not satisfy this criterion unless the portfolio has exactly one application.

Rationale: a single global owner is a bottleneck and a lie about who reviews a slice. Agents need the owning reviewer for the tree they changed, not a default that rubber-stamps every path.

Evidence expected: CODEOWNERS (or equivalent) with a rule per application path; CI or a lint fails an application added without an owner; syntax valid.

Level: 4 · Scope: portfolio · Check: deterministic

Continuous integration and production deploy authenticate to cloud and forge APIs with short-lived workload identity (OIDC or equivalent). Long-lived access keys stored as repository secrets for those paths fail this criterion. Exceptions are enumerated, owned, and time-bounded.

Rationale: a leaked static cloud key is an organization-wide incident. Agents that copy "the secret the last workflow used" will mint more of them unless the platform refuses. Secret-free compile (BLD-110) does not cover how the deploy itself authenticates.

Evidence expected: workflow or deploy config using OIDC or workload identity; absence of static cloud access keys for those jobs, or a dated exception list; a documented identity per application or shared deployer.