PS Product SecurityKnowledge Base

🧾 SOX 404-Style ITGC for Product Security, DevSecOps, Cloud, Kubernetes, and Microservices

Important framing: SOX 404 is about internal control over financial reporting (ICFR). This page does not claim that product-security controls are literally SOX 404 controls. Instead, it shows how a SOX-style ITGC audit mindset can be applied to the software-delivery and platform environment that builds, deploys, and operates business-critical products.

What this page includes

  • a practical audit approach if an auditor reviewed product-security-relevant ITGCs
  • core control domains for repositories, CI/CD, runners, cloud, Kubernetes, and runtime operations
  • auditor questions, evidence examples, and testing ideas
  • sample findings and sample report language

Why this matters

When software delivery materially affects revenue processing, customer data, financial workflows, regulated reporting, or production availability, auditors often stop looking only at "the application" and start looking at the control system around the application:

  • who can change code;
  • who can approve releases;
  • how build pipelines are protected;
  • how production access is governed;
  • how secrets, keys, and infrastructure changes are controlled;
  • how evidence is produced and retained.

That is where a SOX-style ITGC lens becomes useful for Product Security.

The short version

A SOX-style auditor would usually examine five things:

  1. scope and ownership — which systems are in scope, and who owns the controls;
  2. design effectiveness — whether the control is well-designed to prevent or detect the bad outcome;
  3. operating effectiveness — whether the control actually ran during the audit period;
  4. evidence quality — whether logs, approvals, tickets, and reports are durable and trustworthy;
  5. exceptions and remediation — whether failures are tracked, risk-accepted, or fixed in a governed way.

High-level control model

flowchart LR A[Source repo] --> B[CI pipeline] B --> C[Artifact / image / provenance] C --> D[Deployment approval] D --> E[Cloud / Kubernetes runtime] E --> F[Monitoring / logging / IR] A1[Access control + branch protection] --> A B1[Runner isolation + secrets control] --> B C1[Signing + attestation + registry policy] --> C D1[Release sign-off + escalation path] --> D E1[IAM + network + posture + drift control] --> E F1[Audit trail + evidence retention] --> F

Core ITGC-style domains for Product Security

ITGC family Product-security interpretation Typical control objective
Logical access repo, cloud, K8s, secrets, CI/CD, break-glass access only authorized users and workloads can perform privileged actions
Change management code, IaC, pipeline definitions, Helm, manifests, config changes are reviewed, approved, tested, and traceable
Computer operations job execution, monitoring, backups, incident response, key rotation production and supporting systems operate predictably and evidentially
Program development secure SDLC, threat modeling, security requirements, testing security-relevant changes are designed and verified appropriately
Privileged activity oversight admin access, root use, cluster-admin, KMS admins, DBA actions privileged operations are limited, logged, and independently reviewable
Evidence and retention logs, tickets, attestations, approvals, scan results, exceptions the organization can demonstrate that controls existed and ran

Scope examples

A practical scope for a product-security-relevant ITGC review often includes:

  • source-control platform and branch protections;
  • CI/CD system, runners, build agents, and artifact stores;
  • secrets managers, KMS/HSM, signing systems, and certificate services;
  • cloud landing zones, IAM, org policies, network baselines, posture tooling;
  • Kubernetes clusters, admission controls, GitOps controllers, registries;
  • observability, audit logging, alert routing, incident handling, and backup workflows.

Audit approach

1) Planning and scoping

The auditor would usually start by asking:

  • Which products and services are financially or operationally material?
  • Which repos, pipelines, clusters, and cloud accounts deploy those services?
  • Which teams own the controls?
  • Which systems generate authoritative evidence?

2) Walkthroughs

The auditor then performs walkthroughs such as:

  • developer change from commit to merge;
  • merge to build to artifact publication;
  • deployment to staging and production;
  • emergency fix / hotfix path;
  • privileged access request and approval;
  • secret rotation or key-rotation workflow;
  • incident response and post-incident review.

3) Design effectiveness testing

The auditor checks whether the control should work if used correctly.

Examples:

  • branch protection blocks direct pushes to the protected branch;
  • production deployments require an approval from a defined owner group;
  • production secrets are not readable by CI jobs that do not need them;
  • cluster-admin is restricted and audited;
  • audit logs are shipped off-host and retained.

4) Operating effectiveness testing

The auditor tests whether the control did operate during the review window.

Examples:

  • sample 25 production releases and verify required approvals existed;
  • sample 20 privileged access grants and verify request, approval, and expiry;
  • sample 15 emergency changes and verify post-hoc review occurred;
  • sample runner jobs and verify they used the expected identity and secret scope;
  • sample KMS key-rotation or certificate-rotation events and verify evidence.

Auditor question bank by domain

1) Repository and source-control governance

What the auditor asks

  • Are direct pushes to main or release branches blocked?
  • Are CODEOWNERS or equivalent reviewer rules enforced?
  • Is admin bypass possible, and if so, who can do it?
  • Are service accounts separated from human users?
  • Is commit signing or verified provenance required anywhere?

What evidence they collect

  • screenshots or exported branch-protection settings;
  • CODEOWNERS files and repo policy settings;
  • access-control exports for repo admins and maintainers;
  • samples of PRs showing reviewers, approvals, and merge checks;
  • audit logs for branch-protection changes and repo-admin changes.

Common findings

  • repository admins can merge without required review;
  • critical repos lack enforced review or status checks;
  • security-sensitive workflow files are editable by broad engineering groups.

2) CI/CD pipeline and runner security

What the auditor asks

  • Who can edit pipeline definitions?
  • Are production deployment jobs segregated from ordinary test jobs?
  • Are runners shared across trust boundaries?
  • Can forked or untrusted code reach secrets?
  • Are artifacts signed or attested before promotion?

What evidence they collect

  • pipeline protection rules;
  • runner inventory and runner registration model;
  • job logs showing environment protections and approvals;
  • artifact attestations, SBOMs, signatures, and provenance records;
  • evidence that deployment jobs use workload identity instead of static secrets.

Common findings

  • shared runners process both trusted internal jobs and untrusted pull-request jobs;
  • protected variables can be accessed from non-production or unreviewed workflows;
  • pipeline definitions for deployment are stored in repos without strong reviewer controls.

3) Cloud and IAM

What the auditor asks

  • How are production accounts or subscriptions segregated from lower environments?
  • Who can assume privileged roles?
  • Are access grants temporary or standing?
  • Are root / owner / break-glass accounts controlled and monitored?
  • Are organization-level guardrails enforced?

What evidence they collect

  • IAM role inventory and trust policies;
  • JIT / PAM workflow records;
  • CloudTrail / Activity Log / audit-log exports;
  • evidence of MFA, conditional access, SCP / org-policy settings;
  • samples of privileged role assumption and approval records.

Common findings

  • production-admin roles have excessive standing membership;
  • role assumptions are not independently reviewed;
  • cloud control-plane audit logging is enabled but not centralized or retained adequately.

4) Kubernetes and deployment plane

What the auditor asks

  • Who can apply manifests to production namespaces?
  • Is deployment done directly or only through GitOps controllers?
  • Are admission controls enforced, monitored, and exception-governed?
  • Who can change RBAC, NetworkPolicy, or secrets?
  • Are cluster-admin and namespace-admin roles tightly limited?

What evidence they collect

  • cluster RBAC exports;
  • GitOps controller configuration and sync history;
  • admission-policy definitions and violation logs;
  • namespace protection patterns;
  • samples of production changes showing ticket → PR → build → deploy → audit trail.

Common findings

  • kubectl direct access bypasses the documented GitOps promotion path;
  • admission policies run in audit or warn mode only and are not governed;
  • cluster-admin is widely granted to platform engineers without time-bounded activation.

5) Secrets, keys, certificates, and signing

What the auditor asks

  • Where are production secrets stored and how are they injected?
  • Who can read, rotate, or disable keys?
  • Are signing keys separated from encryption keys?
  • Are rotations periodic, event-driven, or manual?
  • Are certs and trust bundles distributed with evidence of issuance and revocation?

What evidence they collect

  • vault / KMS policy exports;
  • key-rotation status and logs;
  • certificate issuance and revocation records;
  • evidence that secrets are not stored in plain text in repos or CI settings;
  • signing and verification policy documents plus sample release attestations.

Common findings

  • the same operator group can issue, approve, and rotate the most sensitive keys;
  • rotation exists on paper but no operating evidence is available;
  • backup encryption keys and production encryption keys are not separated.

6) Logging, monitoring, incident response, and evidence retention

What the auditor asks

  • Which logs are authoritative for change and privileged activity?
  • Can admins disable or erase logs locally?
  • Are logs centralized and immutable enough for investigation?
  • Are incidents classified, escalated, and post-reviewed?
  • Are alerts routed to owned teams with evidence of action?

What evidence they collect

  • centralized logging architecture;
  • retention settings and object-lock / WORM settings where relevant;
  • examples of detection-to-ticket workflows;
  • incident records, timelines, and postmortems;
  • evidence of quarterly or monthly privileged-activity reviews.

Common findings

  • local logs exist but remote immutable retention is missing;
  • incident tickets do not consistently link to affected assets and remediation evidence;
  • privileged log-review control is manual and not performed consistently.

Baseline control set an auditor would likely expect

Domain Baseline control Example test
Repo protected branches + required reviews + required checks inspect settings and sample merged PRs
CI/CD protected environments + runner segregation + secret scoping sample prod deploy jobs and runner mappings
Artifact signed / attested artifacts + trusted registry policy inspect sample artifact and verification logs
Cloud IAM least privilege + MFA + JIT/PAM for privileged roles inspect role grants and sampled activations
Kubernetes RBAC minimization + GitOps control + admission enforcement inspect role bindings and deployment history
Secrets / KMS centralized secret storage + separated key duties + rotation evidence inspect policies, rotation records, and access logs
Logging centralized off-host logs + retention + restricted deletion inspect pipeline, cloud, and cluster log shipping
Release security sign-off + defined acceptance criteria + escalation path sample releases and sign-off artifacts

Examples of evidence packages

A strong evidence set usually includes a mix of configuration evidence, transaction evidence, and review evidence.

Configuration evidence

  • repo protection exports;
  • CI environment-protection settings;
  • IAM policies and trust relationships;
  • Kubernetes RBAC and admission policy manifests;
  • KMS / Vault policies and rotation settings.

Transaction evidence

  • sampled pull requests;
  • sampled deployment runs;
  • sampled role-assumption events;
  • sampled secret-rotation or certificate-issuance events;
  • sampled incident tickets and change tickets.

Review evidence

  • quarterly access reviews;
  • privileged-activity review records;
  • exception approvals and expirations;
  • risk acceptance records;
  • post-release or post-incident follow-up actions.

Sample findings

Example 1 — insufficient segregation in CI/CD

Observation
Production deployment workflows are editable by the same engineering group that can also approve and execute those workflows.

Risk
A single actor can modify, approve, and deploy production code without an independent preventive control.

Why the auditor cares
This weakens segregation of duties and reduces confidence that unauthorized or unsafe production changes would be prevented or detected.

Recommendation
Restrict workflow-edit permissions, require independent approval for protected environments, and move deployment definitions or reusable workflows under stronger ownership.

Example 2 — privileged cloud access not time-bounded

Observation
Standing membership exists in production-admin roles, and no JIT or break-glass governance evidence was produced.

Risk
Persistent privileged access increases the likelihood and blast radius of unauthorized changes or unreviewed control overrides.

Recommendation
Implement JIT access, mandatory ticket linkage, MFA, and periodic access recertification for privileged roles.

Example 3 — logs can be altered by administrators

Observation
Audit-relevant logs are stored locally on systems accessible to privileged operators. No compensating immutable remote retention control was evidenced.

Risk
A privileged actor may alter, truncate, or remove evidence of unauthorized actions.

Recommendation
Ship logs off-host to a restricted central store, enable retention controls, and separate log administration from platform administration where feasible.

Example 4 — deployment plane bypass

Observation
The documented GitOps path exists, but sampled production changes show direct kubectl apply activity from user identities.

Risk
Changes can bypass review, testing, and auditable promotion gates.

Recommendation
Constrain direct cluster access, enforce deployment through the approved controller path, and alert on manual production mutations.

Example report language

Sample issue write-up

Title: Production deployment controls do not provide sufficient segregation of duties

Criteria:
Management has stated that all production changes must be reviewed, approved, and deployed through protected CI/CD workflows.

Condition:
During testing of 25 sampled releases, 7 releases were deployed through workflows editable by the same team that could approve and execute the deployment. In 2 cases, direct cluster changes bypassed the documented GitOps path.

Cause:
Workflow ownership and environment protection rules were not aligned to the production change-control design.

Effect:
Unauthorized or unsafe changes may be introduced into production without an independent preventive control, reducing assurance over the integrity of the deployment process.

Recommendation:
Restrict workflow modification rights, enforce independent environment approval, reduce direct cluster access, and alert on deployment-path bypass events.

Sample management action plan

Management agrees with the observation.

Planned actions:
1. Move production deployment workflows to a restricted platform-owned repository.
2. Require one approver outside the implementation team for production deployments.
3. Disable direct human write access to production namespaces except approved break-glass roles.
4. Implement weekly review of deployment bypass alerts.

Target date: 2026-06-30
Control owner: Head of Platform Engineering
Security co-owner: Director of Product Security

Practical audit plan template

Phase Example activities
Scoping identify in-scope products, repos, pipelines, clusters, accounts, and owners
Walkthroughs follow one normal release, one emergency change, one privileged-access flow
Control design testing inspect configuration and policy design
Operating effectiveness testing sample approvals, deployments, access events, rotations, and reviews
Deficiency evaluation classify deficiency, significant deficiency, or material weakness analog
Reporting issue findings, management responses, target dates, and re-test plan

Control design principles that make audit easier

  • prefer preventive controls over detective-only controls for production changes;
  • use central systems of record for approvals, logs, and role grants;
  • make emergency paths explicit and rare;
  • separate key roles: developer, reviewer, release approver, platform admin, security approver, audit reviewer;
  • design evidence generation as part of the control, not as a manual afterthought.

External references

  • PCAOB AS 2201 — integrated audit of internal control over financial reporting
  • COSO Internal Control — Integrated Framework
  • NIST SP 800-218 (SSDF)
  • SLSA provenance and software supply-chain guidance

Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.