DevSecOps: A journey to protect your applications
In the context of continuously evolving technology, ensuring the security, speed, and quality of software applications is essential. One of the modern approaches to meet these requirements is through the DevSecOps (DSO) pipeline. During my research for my master’s thesis, I also studied the DSO model and, along with my existing experience, built a DSO pipeline to protect my application. I will share with you right now.
Proposed DSO Pipeline
Overview
The DevSecOps pipeline consists of 12 stages, starting from triggering through development events, security checks of the source code, building and testing containers, to signing and deploying Docker images, with continuous security monitoring and management throughout. The stages in the pipeline include:
- Trigger: The pipeline is triggered by events such as merges, commits, timers, or Jenkins jobs.
- Load Artifact: Artifacts like trained models, code applications, and library requirements are loaded into the system.
- Store Artifacts: Artifacts are stored in locations such as S3 buckets, Nexus, or via FTP for future reference and access.
- Security and Quality Tools: Tools like Gitleak, Sonarqube, and Trivy are used to detect security vulnerabilities and assess code quality.
- Build Image: A Docker image is built using a base image with the minimal necessary libraries and dependencies to enhance security.
- Container Testing: Container scans and testing with tools like DAST and IAST are performed to identify security vulnerabilities.
- Quality Gate: Policies and rules are applied to ensure only code meeting security and quality standards proceeds to the next stages.
- Sign Docker Image: Docker images are signed to verify their integrity and origin.
- Save Signed Image: Signed images are stored securely in locations like S3 buckets, Nexus, or via FTP.
- Final Testing: The Docker image undergoes final verification, including infrastructure scans and compliance checks.
- Final Quality Gate: A final quality gate applies policies and rules to ensure all standards are met before deployment.
- Deployment: The application is deployed with Runtime Application Self-Protection (RASP) to ensure real-time security monitoring and protection.
Detailed Analysis
Stage 1 — Trigger the Pipeline
The pipeline trigger when:
- Merge request
- Commit code
- Timer
- Jenkins job
At this stage, The pipeline is triggered by events such as merges, commits, scheduled times, or the execution of a Jenkins job.
Stage 2 — Load Artifact
Load artifact:
- Trained model
- Code application
- Library requirement
At this stage, artifacts such as trained models, application source code, and library requirements are pulled from stored to prepare for the build and test process.
Store Artifacts:
- AWS S3 bucket
- Nexus
- FTP
Artifacts are stored in storage systems like S3, Nexus, or through FTP. We should maintain a whitelist for external libraries and components used in the application, store them on our system, and conduct regular vulnerability assessments. It is advisable to avoid directly pulling them from the internet.
Stage 3 — Testing Tools
Tools:
- Gitleak
- Sonarqube
- Trivy
- OWASP dependency-check
- Checkov
- TFLint
- terraform-compliance
- tfsec
- OpenPubKey
At this stage, it is crucial to conduct security testing on all artifacts prior to deployment in production. These tools serve to examine the source code, IaC, identify potential security vulnerabilities, assess code quality, and confirm their integrity and provenance.
Stage 4 — Quality Gate
Gate:
- Policy/Rule check
At this stage, We establish policies and rules to ensure that only code that meets the requirements can progress to the next stages.
In the modern context, organizations frequently categorize their information systems into various levels based on the type of information processed. Typically, information is segmented into four distinct classifications.
The number of classification levels in an organization’s system may vary based on its size. Typically, a system is categorized into four levels, ranging from level 1 to level 4. This classification allows for the development of specific policies for each level, which may include the minimum severity permitted and the allowable number of vulnerabilities when deploying an application into the production environment.
You can refer to the sample matrix table below.
Explain details about matrix :
- At system level 1, the quality gate will pass if the minimum vulnerability severity is classified as HIGH, MEDIUM, or LOW, and the minimum number of vulnerabilities is 1 for HIGH, 2 for MEDIUM, or 3 for LOW.
- This applies to both system level 2 and level 3 as well.
- At system level 4, I consider this level to be the highest, therefore the quality gate will pass provided there are no vulnerabilities.
This matrix requires fine-tuning to align with the risk appetite of the system under your management.
Quality Gate — PASS = Security
Stage 5— Build Image
Build image:
- Base image
- Least library/dependency
At this stage, after passing all policies and rules, we construct the Docker image for the application. The concept involves using base images with only the essential libraries and dependencies to minimize risk, bolster security, and ensure it is extremely lightweight.
Today, the traditional method of deploying applications on a server is giving way to a more flexible approach. In this new method, an application is segmented into microservices, packaged into images, and executed as containers. This stage can be omitted if your application does not utilize this deployment strategy.
Stage 6 — Container Testing
Tools:
- Synk
- Docker scout
- Trivy
- Clair
- Burpsuite
- Acunetix
- OWASP Zap
At this stage, perform container scans on the newly built image to detect security vulnerabilities using Dynamic Application Security Testing (DAST) tool and Interactive Application Security Testing (IAST) tool.
Stage 7 — Quality Gate
Gate:
- Policy/Rule check
Once again, policies and rules are applied to ensure quality before proceeding to the next steps.
Quality Gate — PASS = Security
Stage 8 — Sign Docker Image
Signing:
Signing Docker images is crucial to ensure their integrity and origin.
Tools:
- OpenPubKey
- Docker content trust key
Stage 9 — Store Signed Image
Store Artifacts:
- AWS S3 bucket
- Nexus
- FTP
Save the signed images in the storage systems.
Stage 10 — Final Testing
Tools:
- Nessus
- NMap
- OpenSCAP
- OpenPubKey
At this stage, conduct a vulnerability check on the infrastructure to be deployed and confirm the image version designated for the production environment.
Stage 11 — Final Quality Gate
Gate:
- Policy/Rule check
Confirm that the final product complies with all quality standards prior to deployment.
Quality Gate — PASS = Security AND Compliance
Stage 12 — Deployment
Tools:
- RASP
Utilize Runtime Application Self-Protection (RASP) for real-time monitoring and safeguarding of your application.
Ensure the RASP agent is correctly integrated into the server or pod hosting the application to bolster its security.
Key Management
Tools:
- Hasicorp Vault
- AWS Secret Manager
- AWS Key Management Service
Managing security keys, including secret keys, public keys, and private keys, is crucial for protecting sensitive data at all stages.
Monitoring
Tools:
- Telegram/ Slack
- Defect Dojo
- ELK
- PagerDuty
- Prometheus & Grafana
Implementing notifications, vulnerability management, and event/logging across all stages is essential to effectively monitor and manage vulnerabilities. It is crucial to collect and analyze all critical logs to promptly detect security issues or system failures.
The DevSecOps pipeline aims to enhance the software development lifecycle by embedding security practices at each phase, from inception through deployment. This approach not only secures the quality of the end product but also bolsters the application’s security posture. The Github repository in the resources section provides additional information on DevSecOps.
Contribution
We welcome contributions from the community to help us expand and improve this DevSecOps pipeline and repository. If you have suggestions, tools, or resources that you believe should be included, please feel free to submit a pull request or open an issue.
Resources:
Github Repository: MLSecOps-DevSecOps-Awesome
