71 lines
2.9 KiB
Markdown
71 lines
2.9 KiB
Markdown
Title: CI/CD Security Standard
|
|
Document ID: [STD-CICD-001]
|
|
Version: 0.1 Draft
|
|
Status: Draft
|
|
Owner: CISO (Paul Jenkins)
|
|
Approver: CISO (Paul Jenkins)
|
|
Classification: Internal
|
|
Effective date: [DD Month YYYY]
|
|
Review date: [DD Month YYYY]
|
|
|
|
# CI/CD Security Standard
|
|
|
|
## Purpose
|
|
|
|
This standard defines the minimum security requirements for continuous integration, continuous delivery, and automated build and deployment workflows.
|
|
|
|
## Scope
|
|
|
|
This standard applies to source control integrations, build systems, test pipelines, artefact repositories, deployment automation, and related engineering workflow components within the ISMS scope.
|
|
|
|
## Mandatory Requirements
|
|
|
|
CI/CD systems must be access-controlled and restricted to authorised users, services, and automation identities.
|
|
|
|
Changes to pipeline definitions, build configurations, deployment workflows, and release automation must be subject to review and approval.
|
|
|
|
Build and deployment workflows must provide traceability between approved source changes, generated artefacts, and deployed outputs.
|
|
|
|
Secrets used by CI/CD systems must be managed according to the approved secrets management approach and must not be exposed through pipeline logs or insecure configuration.
|
|
|
|
Production deployment paths must include appropriate separation of duties, approval, or equivalent compensating control based on risk.
|
|
|
|
Build environments and runners must be managed and hardened according to approved configuration and access requirements.
|
|
|
|
Pipeline activity, administrative changes, and failed or unusual security-relevant events should be logged and reviewed where appropriate.
|
|
|
|
Artefacts promoted to production should originate from approved and traceable build processes.
|
|
|
|
## Implementation Guidance
|
|
|
|
BlackDice should design CI/CD controls to support rapid engineering while preserving change integrity and production safety.
|
|
|
|
The standard should be applied consistently to application code, infrastructure as code, policy-as-code, and deployment configuration where these contribute to service delivery.
|
|
|
|
Where third-party hosted build or deployment services are used, supplier and shared-responsibility considerations should be documented.
|
|
|
|
Higher-risk deployment paths, including production and security-sensitive platform changes, should receive stronger approval and monitoring controls.
|
|
|
|
## Roles and Responsibilities
|
|
|
|
- [Role] must define CI/CD security expectations.
|
|
- Engineering and platform owners must implement compliant pipeline controls.
|
|
- Approvers and reviewers must assess high-risk changes before production deployment.
|
|
|
|
## Exceptions
|
|
|
|
Exceptions must be documented, justified, risk-assessed, approved, and reviewed.
|
|
|
|
## Related Documents
|
|
|
|
- Secure Development Policy
|
|
- Change Management Policy
|
|
- Secrets Management Standard
|
|
- Secure Code Review Standard
|
|
|
|
## Version Control
|
|
|
|
| Version | Date | Description of Change | Author |
|
|
| --- | --- | --- | --- |
|
|
| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |
|