Ship APIs with verifiable controls from design to production
Use Zeph Tech’s field research to fuse OWASP ASVS/SAMM guardrails, NIST SSDF practices, SLSA Level 3 provenance, PCI DSS 4.0 Requirement 6 evidence, and CNCF policy engines into a single operating model.
Updated with OAuth 2.1 PKCE patterns hardened for Node.js 22 LTS, GitHub Advanced Security for Azure DevOps rollout telemetry, and Kyverno API gateway policies aligned with Kubernetes Gateway API.
Reference Zeph Tech briefings: Node.js 22 Active LTS adoption guidance, GitHub Advanced Security for Azure DevOps GA analysis, and GitHub secret scanning push protection GA.
Executive overview
Regulators now expect API programmes to prove that secure design, automated verification, and production guardrails coexist. OWASP ASVS 4.0.3 mandates layered verification across authentication, input handling, and cryptography, while OWASP SAMM 2.1 requires maturity tracking for governance, construction, and verification practices.OWASP ASVS 4.0.3OWASP SAMM 2.1 NIST’s Secure Software Development Framework (SP 800-218) and PCI DSS 4.0 Requirement 6 extend that remit into documented coding standards, authenticated pipeline tooling, and release approvals.NIST SP 800-218 SSDFPCI DSS 4.0 Requirement 6
SLSA Level 3 establishes provenance expectations—ephemeral, isolated build environments with signed attestations—that dovetail with CNCF policy engines such as Kyverno and Gatekeeper for runtime enforcement.SLSA Level 3 SpecificationKyverno policy library This guide maps those frameworks into implementable phases: secure coding foundations, CI/CD provenance, API gateway governance, and AI-augmented validation.
Secure coding guardrails anchored to OWASP and SSDF
Adopt security requirements early by inventorying API threat models, aligning authentication to OAuth 2.1, and enforcing automated verification. OWASP ASVS controls (V2, V3, V4) and NIST SSDF task PO.2.1 call for defined security requirements and reviewable checklists that are version-controlled alongside APIs.OWASP ASVS 4.0.3NIST SP 800-218 SSDF
import 'node:dotenv/config';
import assert from 'node:assert/strict';
import crypto from 'node:crypto';
const issuerUrl = process.env.OIDC_ISSUER?.trim();
const clientId = process.env.OIDC_CLIENT_ID?.trim();
const clientSecret = process.env.OIDC_CLIENT_SECRET?.trim();
const redirectUri = process.env.OIDC_REDIRECT_URI?.trim();
assert(issuerUrl && clientId && clientSecret && redirectUri, 'Missing OIDC configuration');
function base64UrlEncode(buffer) {
return Buffer.from(buffer)
.toString('base64')
.replace(/=/g, '')
.replace(/\+/g, '-')
.replace(/\//g, '_');
}
function createPkcePair() {
const verifier = base64UrlEncode(crypto.randomBytes(64));
const challenge = base64UrlEncode(
crypto.createHash('sha256').update(verifier, 'utf8').digest()
);
return { verifier, challenge };
}
export async function buildAuthorizationUrl({ state, nonce }) {
const { verifier, challenge } = createPkcePair();
const url = new URL('/oauth2/v2.0/authorize', issuerUrl);
url.searchParams.set('client_id', clientId);
url.searchParams.set('redirect_uri', redirectUri);
url.searchParams.set('response_type', 'code');
url.searchParams.set('scope', 'api://default/.default offline_access openid profile');
url.searchParams.set('code_challenge_method', 'S256');
url.searchParams.set('code_challenge', challenge);
url.searchParams.set('state', state);
url.searchParams.set('nonce', nonce);
return { url: url.toString(), pkceVerifier: verifier };
}
export async function exchangeCodeForTokens({ authorizationCode, pkceVerifier, abortSignal }) {
assert(authorizationCode && pkceVerifier, 'Authorization code and PKCE verifier required');
const tokenEndpoint = new URL('/oauth2/v2.0/token', issuerUrl);
const body = new URLSearchParams({
grant_type: 'authorization_code',
client_id: clientId,
client_secret: clientSecret,
redirect_uri: redirectUri,
code: authorizationCode,
code_verifier: pkceVerifier
});
const response = await fetch(tokenEndpoint, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json'
},
body,
signal: abortSignal,
cache: 'no-store'
});
if (!response.ok) {
const detail = await response.text();
throw new Error(`OIDC token exchange failed: ${response.status} ${detail}`);
}
const tokens = await response.json();
assert(typeof tokens.id_token === 'string', 'ID token missing');
assert(typeof tokens.refresh_token === 'string', 'Refresh token missing');
assert(typeof tokens.access_token === 'string', 'Access token missing');
return tokens;
}
export async function revokeToken({ token, hint = 'refresh_token', abortSignal }) {
assert(token, 'Token required for revocation');
const revocationEndpoint = new URL('/oauth2/v2.0/logout', issuerUrl);
const form = new URLSearchParams({
token,
token_type_hint: hint,
client_id: clientId,
client_secret: clientSecret
});
const response = await fetch(revocationEndpoint, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
body: form,
signal: abortSignal,
cache: 'no-store'
});
if (!response.ok) {
throw new Error(`Token revocation failed: ${response.status}`);
}
}
Pair the implementation with automated threat modelling (SAMM GOV:TM) and Node.js permission policies so secret scanning and dependency review guardrails fire before merge.OWASP SAMM 2.1Zeph Tech GitHub push protection analysis
CI/CD provenance, SBOM automation, and pipeline policy
NIST SSDF PW.8, PCI DSS 4.0 Requirement 6.3, and SLSA Level 3 all require authenticated, tamper-evident build pipelines with documented review and attestation steps.NIST SP 800-218 SSDFPCI DSS 4.0 Requirement 6SLSA Level 3 Specification GitHub Advanced Security for Azure DevOps brings CodeQL, secret scanning, and dependency review evidence into Microsoft Defender for DevOps dashboards, satisfying SSDF verification tasks and PCI change-management artefacts.Zeph Tech GHAS for ADO GA briefing
name: build-sign-and-attest
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
workflow_dispatch:
permissions:
contents: read
id-token: write
packages: write
attestations: write
jobs:
build:
runs-on: ubuntu-24.04
env:
NODE_OPTIONS: "--openssl-legacy-provider=0"
permissions:
contents: read
packages: write
id-token: write
attestations: write
steps:
- name: Harden runner
uses: step-security/harden-runner@v2
with:
egress-policy: audit
- name: Checkout
uses: actions/checkout@v4
with:
persist-credentials: false
fetch-depth: 1
- name: Setup Node.js 22 LTS
uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- name: Install dependencies
run: npm ci --ignore-scripts
- name: Run security tests
run: npm run lint && npm test
- name: Build distributable
run: npm run build
- name: Generate CycloneDX SBOM
uses: anchore/sbom-action@v0
with:
path: dist
format: cyclonedx-json
output-file: dist/app-sbom.json
- name: Upload SBOM artifact
uses: actions/upload-artifact@v4
with:
name: app-sbom
path: dist/app-sbom.json
if-no-files-found: error
- name: Create SLSA Level 3 provenance
uses: slsa-framework/slsa-github-generator@v2
with:
build-artifact-path: dist
slsa-version: v1.5
- name: Attest build with GitHub provenance
uses: actions/attest-build-provenance@v1
with:
subject-path: dist/**
- name: Publish package
run: npm publish --provenance --access public
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
Store SBOMs, CodeQL SARIF, and attestation bundles in immutable storage (e.g., GitHub attestations service or OCI registries) and feed drift detections into SOC workflows so Mean Time To Restore aligns with SSDF RV.1 tasks.
API governance, policy-as-code, and runtime segmentation
PCI DSS 4.0 Requirement 6.2 requires that publicly exposed APIs undergo vulnerability identification, authenticated scanning, and patch verification before release; pairing Kyverno, Gateway API, and NetworkPolicy controls ensures runtime enforcement matches design-time expectations.PCI DSS 4.0 Requirement 6Kyverno policy library CNCF policy stacks (Kyverno, Open Policy Agent Gatekeeper, Sigstore admission controllers) keep Kubernetes clusters compliant with Pod Security Standards and zero-trust ingress requirements.Kubernetes Pod Security Standards
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-api-ingress-security
annotations:
policies.kyverno.io/title: Enforce TLS and mTLS guardrails for edge APIs
policies.kyverno.io/category: API Governance
policies.kyverno.io/severity: medium
spec:
validationFailureAction: enforce
background: true
failurePolicy: Fail
rules:
- name: require-nginx-tls-version
match:
any:
- resources:
kinds: [Ingress]
preconditions:
all:
- key: "{{ request.object.metadata.annotations['kubernetes.io/ingress.class'] || '' }}"
operator: Equals
value: nginx
validate:
message: "Public ingress endpoints must restrict TLS protocols to 1.2 and 1.3"
pattern:
metadata:
annotations:
nginx.ingress.kubernetes.io/ssl-protocols: "TLSv1.2 TLSv1.3"
- name: require-mtls-authentication
match:
any:
- resources:
kinds: [Ingress]
preconditions:
all:
- key: "{{ request.object.metadata.annotations['kubernetes.io/ingress.class'] || '' }}"
operator: Equals
value: nginx
validate:
message: "Mutual TLS is required for partner API ingress"
pattern:
metadata:
annotations:
nginx.ingress.kubernetes.io/auth-tls-secret: "platform/edge-mtls"
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
- name: block-privileged-backends
match:
any:
- resources:
kinds: [HTTPRoute]
apiGroups: [gateway.networking.k8s.io]
validate:
message: "HTTPRoute backends serving APIs must not target privileged namespaces"
foreach:
- list: "request.object.spec.rules[].backendRefs[]"
deny:
conditions:
all:
- key: "{{ element.namespace || request.namespace }}"
operator: AnyIn
value: ["kube-system", "istio-system", "cert-manager"]
RACI matrix for secure API delivery
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Threat modelling & OWASP ASVS control mapping | Product engineering | Application security lead | Platform architecture, privacy | Compliance office |
| CI/CD provenance & SLSA attestation reviews | Platform engineering | DevSecOps director | Security operations, procurement | Audit liaison |
| API gateway policy enforcement | Site reliability engineering | Chief information security officer | Network engineering, data protection | Product owners |
| PCI DSS & regulator reporting | Compliance operations | Chief risk officer | Internal audit, legal | Executive leadership |
Testing strategy across the API lifecycle
Testing must operate as a layered defence that validates design assumptions, implementation fidelity, and regression resilience. OWASP ASVS chapters V1–V10 outline control families that map naturally into automated and manual verification stages, while NIST SSDF practice PS.3 calls for comprehensive verification with documented evidence.OWASP ASVS 4.0.3NIST SP 800-218 SSDF
Automated coverage
- Static analysis: Run CodeQL, Semgrep, or SonarQube on every pull request with language-specific rulesets, enabling GitHub secret scanning push protection for credential hygiene.Zeph Tech push protection briefing
- Software composition analysis: Generate SBOMs (SPDX 2.3 or CycloneDX 1.6) and enforce policy checks against high-risk CVEs and license violations before artefact promotion.
- Dynamic testing: Execute OWASP ZAP, Burp Suite Enterprise, or StackHawk in pre-production. Configure authenticated scans with OAuth 2.1 tokens to mirror production flows.
- Fuzzing and chaos: Integrate RESTler or Jazzer fuzzers for negative testing and apply chaos experiments via Gremlin or LitmusChaos to validate resilience under traffic surges and dependency faults.
Human-in-the-loop validation
- Threat modelling workshops: Use STRIDE or PASTA methods during design reviews; capture mitigations in version-controlled diagrams and link to backlog items.
- Secure code reviews: Mandate dual reviewers for high-risk changes (authentication, payment flows) and require reviewers to acknowledge AI-assisted diffs to maintain attribution.
- Penetration testing: Commission independent testers annually or upon major architectural change. Ensure scopes include microservices, GraphQL endpoints, and third-party integrations.
- Bug bounty and VDP: Operate vulnerability disclosure programmes aligned with CISA Binding Operational Directive 20-01 guidance; integrate findings into remediation SLAs.
Coordinate testing artefacts through a central evidence registry. Tag results with API version, environment, and compliance scope (PCI, HIPAA, GDPR) to streamline audits and to prove PCI DSS Requirement 11 coverage.
Runtime enforcement and zero-trust protections
Production APIs require runtime guardrails that assume compromise and constantly validate policy compliance. CNCF projects such as Envoy, Istio, and Gateway API bring programmable enforcement that complements upstream verification.
- Mutual TLS and identity-aware proxies: Enforce mTLS between services using SPIFFE/SPIRE or Istio’s workload identities. For edge enforcement, deploy Envoy-based API gateways with short-lived client certificates.
- Fine-grained authorisation: Combine Open Policy Agent, Cedar (AWS verified permissions), or Zanzibar-style graph engines with JSON Web Token (JWT) claims to evaluate contextual access decisions in under 50 milliseconds.
- Traffic shaping and abuse prevention: Configure adaptive rate limiting (Envoy, Apigee Advanced API Ops) tied to business priorities. Enforce anomaly detection via machine-learning models trained on historic request baselines.
- Data loss prevention: Apply inline content inspection for PCI DSS, PHI, or PII markers. Use hashing or tokenisation for identifiers before logging to align with GDPR data minimisation and CCPA retention rules.
- Runtime security analytics: Stream Gateway API access logs, Kubernetes audit events, and cloud WAF alerts into a SIEM. Map detections to MITRE ATT&CK techniques to speed triage and satisfy SOC 2 CC7 monitoring controls.
Regularly validate runtime defences using automated policy conformance tests (Kyverno CLI, OPA conftest) and quarterly purple-team exercises that simulate credential stuffing, BOLA (OWASP API Top 10 2023 A1), and mass assignment attacks.
Incident response playbooks for API ecosystems
Incident readiness must cover service degradations, data exfiltration attempts, and supply-chain compromises. Align procedures with NIST SP 800-61r2 and ISO/IEC 27035 while satisfying disclosure obligations from regulators and customers.NIST SP 800-61r2ISO/IEC 27035
Prepare
Catalogue APIs, data classifications, and dependencies. Establish communication trees, secure vaults for breach notifications, and tabletop exercises involving legal, PR, and customer success teams.
Detect & analyse
Instrument anomaly detection across API gateways, WAFs, and behaviour analytics platforms. Define thresholds for automatic severity assignment and ensure forensic logging retains request/response payloads with tamper-evident hashing.
Contain, eradicate, recover
Script containment actions—revoking OAuth clients, rotating keys via automated vault workflows, deploying hotfixes with feature flags, and invalidating tokens. After recovery, run root-cause analysis and feed corrective actions into backlog and training plans.
Document breach reporting timelines (e.g., GDPR 72-hour notification, U.S. SEC Form 8-K Item 1.05 four-business-day disclosure for material cyber incidents) and integrate them into the incident orchestration platform so obligations are never missed.U.S. SEC cyber disclosure rule
Global regulatory obligations for API programmes
Security and privacy compliance varies by jurisdiction, so API programmes must map controls to multiple regulatory regimes. Align governance artefacts with the strictest requirements to simplify reporting and reuse evidence.
| Jurisdiction or framework | Key API obligations | Primary references |
|---|---|---|
| European Union — GDPR & Digital Operational Resilience Act (DORA) | Data protection by design, breach notice within 72 hours, ICT risk management, resilience testing, third-party oversight | GDPR Regulation (EU) 2016/679; Regulation (EU) 2022/2554 |
| United Kingdom — FCA/PRA operational resilience & UK GDPR | Identify important business services, set impact tolerances, maintain UK data transfer assessments, align API monitoring with FCA FG 16/5 guidance | FCA operational resilience; ICO UK GDPR |
| United States — PCI DSS, HIPAA, SEC, state privacy laws | Secure payment APIs, protect PHI, report material incidents within four business days, honour state privacy rights (CCPA/CPRA, Colorado Privacy Act) | PCI DSS 4.0; HIPAA Privacy Rule; SEC cyber disclosure rule |
| Asia-Pacific — Singapore MAS TRM 2021, Australia CPS 234, India DPDP Act 2023 | Maintain asset inventories, secure outsourcing, report incidents within one hour (MAS), ensure information security capability for APRA-regulated entities, honour Indian personal data processing obligations | MAS Technology Risk Management; APRA CPS 234; Digital Personal Data Protection Act 2023 |
| Latin America — Brazil LGPD, Mexico Fintech Law | Data subject rights, consent management, secure open banking APIs with consent logs and risk scoring, incident reporting to data protection authorities | Brazil LGPD; Mexico Fintech Law |
Maintain a regulatory matrix linking each obligation to controls, owners, evidence, and testing cadences. Update the matrix quarterly and after each major regulatory release—such as the EU’s Cyber Resilience Act delegated acts or revisions to ISO/IEC 27001—to prevent compliance drift.
Measurement dashboards — DORA and SPACE alignment
High-performing teams monitor both delivery and developer experience. Google’s 2023 Accelerate State of DevOps Report defines elite performance as deploying on-demand (multiple times per day), achieving lead times under 24 hours, change failure rates between 0–15%, and MTTR under an hour.Google 2023 State of DevOps Report The SPACE framework (Satisfaction, Performance, Activity, Communication, Efficiency) provides qualitative and quantitative signals to complement DORA metrics.Microsoft Research SPACE framework
GitHub’s Octoverse 2024 report shows a 65% year-over-year increase in AI-assisted pull requests and organisations using code search plus Copilot shipping 55% more pull requests per developer—metrics that should appear alongside DORA dashboards to capture automation impact.GitHub Octoverse 2024Zeph Tech developer trends briefing
| Metric | Target benchmark | Data source | Notes |
|---|---|---|---|
| Deployment frequency | Multiple deploys per day (elite DORA) | GitHub Actions, Azure Pipelines | Annotate feature flags to avoid counting dark launches. |
| Lead time for changes | < 24 hours (elite DORA) | Value stream analytics, Jira cycle time | Segment by API surface to highlight bottlenecks. |
| Change failure rate | ≤ 15% of releases | Incident tickets, automated rollbacks | Correlate with GitHub Advanced Security autofix adoption. |
| MTTR | < 1 hour | Incident response tooling, PagerDuty | Measure runbook execution times per PCI DSS evidence packages. |
| SPACE satisfaction index | ≥ 75% positive developer sentiment | Quarterly developer surveys, retro insights | Include qualitative notes on AI-assisted review fatigue. |
| AI-assisted PR share | Track YoY delta vs 65% Octoverse benchmark | GitHub Copilot analytics, GHAS insights | Alert when AI PR share rises without matching review capacity. |
AI augmentation for security reviews and governance
Use AI assistants to accelerate triage while maintaining human accountability. GitHub Code Scanning autofix and Copilot pair programming reduce MTTR when combined with enforced review policies and PCI DSS change controls.Zeph Tech GHAS for Azure DevOps rolloutZeph Tech GitHub autofix briefing Align automation with OWASP SAMM OPS:TA practices—documenting AI usage, logging prompts, and monitoring bypass rates.
Cross-train platform, AppSec, and operations teams to interpret AI-generated evidence before attesting compliance submissions—aligning with SAMM governance checks and ensuring PCI DSS quarterly reviews remain accurate.
Implementation roadmap
- Quarter 1: Finalise OWASP ASVS-derived security requirements, onboard GitHub Advanced Security (code, secret, dependency scanning), and deploy foundational Kyverno policies in staging clusters.
- Quarter 2: Enforce SLSA Level 3 provenance across critical services, publish SBOMs to registries, and integrate PCI DSS Requirement 6 evidence into compliance management tooling.
- Quarter 3: Expand runtime governance (Gateway API, NetworkPolicy), instrument DORA/SPACE dashboards, and rehearse regulator-ready incident response covering AI-assisted remediation controls.
- Quarter 4: Conduct independent penetration tests, refresh threat models, and re-baseline maturity against OWASP SAMM and NIST SSDF scorecards ahead of audit cycles.