Think:
- Spoofing
- Tampering
- Repudiation
- Info disclosure
- Denial of Service
- Elevation of privilege
OWASP CI/CD Security Cheat Sheet
A lot of guidance relating to:
- Configuration
- IAM
- Third-party code
- Integrity
- Monitoring
OWASP Top 10 CI/CD Security Risks:
- CICD-SEC-1: Insufficient Flow Control Mechanisms
- CICD-SEC-2: Inadequate Identity and Access Management
- CICD-SEC-3: Dependency Chain Abuse
- CICD-SEC-4: Poisoned Pipeline Execution (PPE)
- CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Controls)
- CICD-SEC-6: Insufficient Credential Hygiene
- CICD-SEC-7: Insecure System Configuration
- CICD-SEC-8: Ungoverned Usage of 3rd Party Services
- CICD-SEC-9: Improper Artifact Integrity Validation
- CICD-SEC-10: Insufficient Logging and Visibility
The OWASP Software Assurance Maturity Model (SAMM):
- Provides a measurable way to analyze and improve an organization's software security posture
- Is a repeatable method to raise awareness and educate on how to design, develop, and deploy secure software through its self-assessment model
- Supports the complete SDLC and is technology and process agnostic.
(For help using the SAMM, see the site or contact one of the many fine SAMM practictioners listed.)
- SAMM covers 15 security practices, including Secure Deployment
- SAMM divides the maturity of each practice into three levels
- Maturity actually on a continuous scale: [0.0 - 3.0]
For Secure Deployment, to achieve each level, certain practices must be getting performed:
| Level | Requirement | Activities |
|---|---|---|
| 1 | Fully documented, up-to-date, accessible deployment process. | Formalize the deployment process and secure the tooling and processes used. |
| Application secrets secured and different per environment. | Limit access to production secrets based on principle of least privilege. Restrict developers from production secrets. |
|
| 2 | Automated process includes security verification. | Automate the deployment process over all stages. Use security verification tests. Alert on vulnerabilities. Keep deployment logs for defined time. |
| Secrets get dynamically injected during deployment. | Inject from hardened stores. Prevent human access to secret storage. Confirm that no secrets remain in source or configuration files. Log and alert any access attempts. |
|
| 3 | Consistently validate artifact integrity. | Process automatically rolls back deployment on integrity breach, using file signatures created at build time. Confirm authenticity of external software. |
| Practice application secret lifecycle management. | Generate/synchronize application secrets using a vetted solution. Application instances use unique secrets. Periodically change and update secrets. |
The ASVS also divides its standards into three levels:
- Level 1 is the bare minimum that all applications should strive for, or for applications do not handle sensitive data.
- Level 2 ensures that security controls are in place, effective, and used within the application. Adequately defends against most current software risks.
- Level 3 is the highest level of ASVS verification, and is typically reserved for apps with significant risk (e.g. military, health and safety, critical infrastructure, etc.)
For deployment, the OWASP (ASVS) calls out the following standards:
Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality. This is not possible without complete access to source code, including third-party libraries.
| Min level | Standard |
|---|---|
| 1 | The application must not load or execute code from untrusted sources. |
| Min level | Standard |
|---|---|
| 1 | Ensure all components are up to date, using a dependency checker during build. |
| 1 | Remove all unneeded features, documentation, sample applications and configurations before deployment. |
| 1 | If application assets (e.g. libraries, CSS) are hosted externally (e.g. a CDN), use Subresource Integrity (SRI) to validate the integrity of the assets. |
| 1 | Disable server and application framework debug modes in production. |
| 1 | Do not expose detailed version information of system components in HTTP responses. |
| 1 | Use HTTP security headers, e.g: Content-Type, Content Security Policy, Strict-Transport-Security. |
| 2 | Verify that third-party components come from pre-defined, trusted, and continually maintained repositories. |
| 2 | Maintain a Software Bill of Materials (SBOM) of all third-party libraries in use. |
| 2 | Sandbox third-party libraries to expose only the required behavior to the application. |
| 2 | Verify that HTTP headers added by a proxy are authenticated by the app. |