DevSecOps : Is your pipeline ready for it?
A compiled R&D for potential security gates/checkpoints in a CI/CD pipeline.
In the previous blog, I talked about why there is a need to integrate security throughout our CI/CD pipeline. Let us try to understand how to do so.
Every pipeline is unique in itself. So, implementing DevSecOps cannot really be thought of as a set of hard and fast rules. Rather it is a culture where the developer needs to understand the potential security gates throughout the pipeline. Apart from best practices, I believe these points are a good start to a DevSecOps engineer, who is thinking to put security checks in a pipeline.
- Image checks:
- Only those images which have been approved for production can be deployed to your cluster. For this purpose, Kubernetes admission controllers, pod security policies, validation of signatures, implementing Servicemesh can work.
- Check if the image contains the use of any passwords/sensitive values or not to be revealed Secrets.
2. Dependency & vulnerability checks:
- Check for deprecated dependencies.
- Automatic security checks (checking code vulnerabilities) when PR is made. Examples of risks when discovered by a security scan, should include possible exploits such as shell execution attacks, weak permissions, SQL injections etc. Should any positive match be made, the security lint tool should have the ability to post details to the repository web UI (for example a GitHub webhook) and recommend the change(s) as a pull request.
- Periodic or event-driven scanning should take place against these dependency lists to check that none of the listed dependencies have any active CVEs or known exploits recorded against them.
- Check if the build is failed.
3. API scanning:
- Trusted third party APIs should be used (if present).
- Deprecated API usage detection.
4. Container scanning:
- Use of Container health index.
- Make use of container isolation.
5. Miscellaneous:
- Proper application logging and monitoring tools should be there.
- Platform audit, license and compliance checks should be done.
- Key Performance Indicators on how secure the application is, can be implemented.
- Config and YAML manifest checks should be performed.
- Linting.
- Be cautious of links within the code, which can be exploited into a phishing attack.
- Beware of possible license deprecations.
Besides this, additional things to ponder upon while incorporating checks in a pipeline are :
- Can user X call or access operation Y on resource Z?
- What clusters should workload W be deployed to or restricted from?
- What tags must be set on resource R before it’s created?
- What access controls should X microservice utilize?
For a DevSecOps engineer, there is no particular roadmap to give a headstart. I just tried to compile a few points which further helped me in narrowing down the action items for my use case.
If you found this article insightful or of the slightest help, give it a few claps. Feel free to reach out in case of any queries. Happy learning!