The security team role — the advisory and audit

The security team is an advisor and an auditor, not a gatekeeper. The security team encodes its policy as code (SAST, SCA, SBOM, signed commits, vulnerability gates) and ships that policy through the platform team’s paved road. The security team audits by querying the pipeline output - the SBOM, the signatures, the scan results - not by attending change-advisory meetings. The security team is a peer of the platform team, not a layer above it.

The advisor and auditor model

The advisor-and-auditor model is the structural opposite of the gatekeeper model. The gatekeeper model puts a human in the critical path of every change: the change is approved only when a security team member signs off. The advisor-and-auditor model puts code in the critical path of every change: the change is approved only when the security policy as code passes.

flowchart LR
    subgraph SEC["Security team"]
        POL["Policy as code:\nSAST rules, SCA rules,\nSBOM requirements,\nsignature policy,\nvuln gates"]
        AUD["Audit queries:\nSBOM, signatures,\nscan results, drift"]
    end
    subgraph PLAT["Platform team"]
        PIPE["CI pipeline"]
    end
    subgraph APP["Application team"]
        PR["Pull request"]
    end
    SEC -->|"publishes policy"| PLAT
    APP -->|"opens PR"| PLAT
    PLAT -->|"runs policy from SEC"| APP
    SEC -->|"queries output"| PLAT
    SEC -->|"queries output"| APP

The security team’s relationship with the platform team is provider-to-consumer: the security team publishes the policy; the platform team runs it. The security team’s relationship with the application team is auditor-to-audited: the security team queries the pipeline output; the application team owns the change.

The gatekeeper model is slow and unscalable. A team of three cannot review 200 pull requests per week. The advisor-and-auditor model is fast and scalable: the policy runs on every pull request, and the audit query answers the question the gatekeeper would have answered manually.

The policy as code

The security team’s product is the policy as code. The policy is a versioned artefact in the security team’s repository; the platform team’s CI workflow consumes the policy and applies it to every pull request.

The policy as code has six components:

1. SAST rules. Static analysis rules that flag dangerous patterns - hardcoded secrets, unsafe deserialisation, SQL injection, command injection. The rule set is versioned; rule additions are pull requests with rationale.
2. SCA rules. Software composition analysis rules that flag vulnerable dependencies. The rule set references a vulnerability database; the database is pinned and versioned.
3. SBOM requirements. Every artifact must emit a Software Bill of Materials in a standard format (SPDX or CycloneDX). The SBOM is signed and queryable.
4. Signature policy. Every commit must be signed; every artifact must be signed (cosign). The signing identity is checked; the signature is verified.
5. Vulnerability gates. A pull request that introduces a dependency with a known CVE above the threshold fails the build. The threshold is versioned; changes are pull requests.
6. Drift detection. The production cluster’s actual state is compared to the declared state; drift is alerted and not silently tolerated.

The policy is not a one-time document. The security team maintains it the same way the platform team maintains the paved road: versioned, tested, deprecated.

The audit as a queryable artefact

The security team’s audit function is a query against the pipeline output:

• Which services have an SBOM? A query against the artifact registry returns the emitters; the rest are the gap.
• Which artifacts are signed? A query against the signature store returns the signed; the unsigned are the gap.
• Which dependencies have a known CVE? A query against the SBOMs joined with the vulnerability database returns the vulnerable; the unpatched are the gap.
• Which commits are unsigned? A query against the Git log returns the unsigned; the unsigned are the gap.

The audit query is faster than the gatekeeper review and the audit gap is visible rather than discovered during a meeting. The security team that audits by query answers the auditor’s questions in seconds; the security team that audits by meeting cannot answer them at all.

What the security team does not own

The security team’s boundaries are explicit:

• Approve pull requests. The policy as code approves; the security team owns the policy, not the approvals.
• Run the CI pipeline. The platform team runs CI; the security team provides the policy the pipeline executes.
• Own the cluster. The infrastructure team owns the cluster; the security team queries it for compliance.
• Fix application bugs. The application team owns the application; the security team flags, the application team fixes.

Production discipline

1. Publish the policy as code in a versioned repository. The repository’s release tags are the policy versions the platform team consumes.
2. Make the policy the gate. A pull request that does not pass the policy fails the build; no human override is permitted.
3. Audit by query. Track SBOM coverage, signature coverage, vuln-gate pass rate, and drift incidents as dashboard metrics, not as meeting topics.
4. Treat the policy as a living artefact. Rule additions, threshold changes, and deprecations are pull requests with the same review discipline as any other change.

Cross-course references

• This course, Part CIII (RepoPitfalls) covers the committed-secrets failure mode the SAST rules prevent.
• This course, Part CIV (PipelinePitfalls) covers the vulnerability-gate failure mode the SCA rules prevent.
• Observability course - the security audit dashboard joins the SBOM, the signature store, and the vulnerability database.

Quiz