How do you identify and contain risks when decisions are being made quickly and often by self-managing delivery teams? How can you prove compliance when developers are pushing their own changes to production?
Five quick wins for securing continuous delivery:
- Automated safety checks in your pipelines
- Lightweight risk assessments
- Security Unit Tests
- Secure the software supply chain
- Self-service code scanning
1. Automated safety checks in your pipelines
Why? Because you are making changes often, it is easier to make mistakes. You need simple, fast checks that find them before the bad guys. This makes auditors happy because they can see that policies are being enforced.
How? Add tests/assets for common mistakes to the end of the automated build/deploy pipeline in test and production. This includes: default/missing credentials; SSL and HTTPS settings; known critical vulnerabilities; file and user permission, and, open ports.
Tools and frameworks available include:
- Netflix Security Monkey, Conformity Monkey
- Gauntit
- OWASP ZAP Baseline Scan
- OSQuery
- InSpec
- Cloud services like AWS Inspector
2. Lightweight risk assessments
Why? Teams are making decisions quickly, so you want them to be able to do this safely and to look for potential new risks upfront before coding starts. You get security/compliance stories into the backlog so that they can be planned for, and so you can find the right tools, libraries, and frameworks. It also makes the risks visible to the teams and management.
How? Check out Mozilla’s Rapid Risk Assessment. It’s a good example.
3. Security Unit Tests
Why? These prove that vulnerabilities are being fixed correctly. They teach developers how to “step off of the happy path” in their testing, and it will catch/prevent regressions. Normal tests prove it works, not that it might not work, and developers need to write happy tests, sad tests, and bad tests.
How? As you find vulnerabilities, write a test first so you can prove it exists. Then, have developers fix it and then run the test again. They can use tools such as JUnit, NUnit, and Jasmine.
4. Secure the software supply chain
Why? Third-party code injects risk and security vulnerabilities and technical debt: known security vulnerabilities; abandoned and out-of-date code; and, license risks. It is relatively easy, there is some lifting at the front, but, once you do it, you have a nice control set going forward.
How? Get a tool to automatically catalog dependencies and check against vulnerability databases. Integrate it into the Continuous Delivery pipeline and fail builds on serious problems.
Tools include:
- OWASP Dependency Check
- Retire JS
- Anchore Engine
- Nexus Lifecycle/Firewall
- Licensed
- GitHub security alerts
5. Self-service code scanning
Why? Automated static analysis scanners can catch common coding mistakes and bad practices. This is the only way to cover large code bases, and it backstops code reviews because reviewers won’t waste time on superficial and subtle coding problems. It fits naturally into workflows and results can be fed directly back to developers.
How? Focus on high-risks and high-fidelity rules. Accuracy and speed is more important than completeness in Continuous Integration/Continuous Delivery. Tools include:
- Java – SpotBugs + FindSecurityBugs plugin + FBContrib plugin
- .NET – Puma Scan, Roslyn Security Guard, and Microsoft’s DevSkim
- SonarLint IDE plugin for various languages
- Ruby on Rails – Brakeman
- Docker – Hadolint
- Git Pre-commit checks to catch secrets, etc. on check in: Talisman, Yelp’s pre-commit, git-secrets
- Git tools to scan reports for secrets: TruffleHog, git-all-secrets
- A list of static analysis tools
Original Source: https://blog.sonatype.com/5-quick-wins-for-securing-continuous-delivery
