Secure Software Delivery and CI/CD Controls

A pipeline is a trust boundary

Source control, review, build systems, dependencies, package registries, build agents, artifacts, deployment identities, infrastructure as code, and approval gates form a chain of trust. A passing pipeline does not prove software is secure or that deployment succeeded operationally. It records that a defined process reached a result; teams still need bounded evidence about inputs, permissions, tests, release scope, environment, and post-deployment behavior.

CI/CD trust-boundary table

Stage	Control questions
Source and review	Who can merge, change branch protection, approve exceptions, or alter build definitions?
Build and dependency	Which agent runs the build, which credentials it receives, and how are dependencies and artifacts identified?
Promotion and deployment	Which identity promotes an artifact, which environment is targeted, and who approves privileged changes?
Validation and rollback	What evidence confirms the intended version and configuration, and what rollback path is tested?

Pipeline review checklist

Protect important branches, build definitions, secrets, and deployment configuration with separated duties appropriate to the team.
Use isolated or resettable build environments where practical, with scoped credentials and a documented owner for build images and agents.
Record artifact identity, source revision, dependency review evidence, signing or provenance information where supported, and promotion history.
Separate development, test, and production identities and data. A convenient shared credential can collapse the environment boundary.
Review infrastructure-as-code changes alongside the application change, including network, identity, secret, logging, and rollback effects.

Release workflow

Define the release scope, approved change, artifact identity, deployment identity, environment, success criteria, and rollback owner.
Confirm required review and automated checks have results, then record any accepted limitations rather than treating a green status as full assurance.
Promote the identified artifact; do not rebuild an untracked equivalent during the release.
Validate a bounded set of operational signals: deployed version, health checks, expected authorization, logs, critical dependencies, and monitoring.
Record outcome, anomalies, rollback decision, and follow-up work. Emergency changes should still leave an auditable decision trail.

Fictional deployment workflow

A service release changes an API and an infrastructure policy. The pipeline passes, but post-deployment validation finds a workload identity cannot read a newly required configuration value. The release owner pauses promotion, uses the documented rollback path, and retains the artifact, approval, denied event, and corrective change. The pipeline result was useful evidence, but it did not substitute for operational validation.

Common mistakes

Common mistakes include giving build agents standing production administration, allowing an artifact to be rebuilt between review and release, or treating rollback as a button without checking data, schema, and dependency compatibility. Emergency access should be time-bound and logged; it should not become a permanent alternative to review and deployment controls.

Build-agent and emergency-change checklist

Maintain an inventory of build agents, runner images, package registries, service identities, network access, and owners. Review whether agents can access unnecessary production resources or retain state between unrelated builds. For an emergency change, record why the normal path could not be used, who approved the deviation, the exact artifact and target environment, validation results, rollback owner, and required follow-up review. Speed may be necessary; evidence and scoped permissions still matter when the normal process is compressed.