Agile principles changed the way the software industry functions and it was indeed considered to be the modern software evolution. The way software is built, tested, and delivered is changed, some of the companies do service delivery multiples times a day in the SAAS model. FAANG organizations has been very successful in adopting this methodology.
DevOps changed the world!
The engineering & operations were brought together to a table and this ensured the product envisioned is indeed getting built and the gap between the expectation vs the reality was narrowed down. The friction between Ops guys and Dev guys was reduced!
Still, the missing piece really was the security testing which used to be done at a much later stage where the entire product was built. It was then tested for security vulnerabilities, exploited to see if it can be broken. There is nothing wrong with it; Just that the speed was lost which was attained using Agile and DevOps practices. The cost of fixing any defect is 10 folds if it is not identified at the source closer to code.
DoD Enterprise DevSecOps Reference Design -
If there was a practice to integrate security testing all along the way how software was created, it would complement the 'speed of light delivery requirements yielding a product well tested for security as well.
The subject might really look complicated. To clarify; if we were to integrate security controls throughout each of the stages of the DevOps pipeline, security would be inbuilt. Helps ensure that security is tested for in each of the stages instead of at the very end.
Remove that central team doing security testing, instead build security throughout the development process. Bring the security engineering practices & people to each stage of DevOps.
Let's look at how -
During the planning stage for a sprint, also plan for security. Come up with a threat model for the component that is being developed. This would mean coming up with;
- Security Baseline, Security Posture expected from that component
- Compliance requirement - compliance as applicable to that component
- Do threat modeling
Here is where you integrate plugins to do static analysis (SAST) of the code that is written by a developer. You can integrate specialized tools like SonarQube at the IDE level and fix issues reported by the tool automatically. Then at the code commit level, ensure that none of the code is committed without meeting the secure coding guidelines. SonarQube can help you with that as well.
Readability of code - intriguing how it matters to security?
Well, a well-written code is easy to maintain. If not well written it would be poorly maintained in the future by the same developer or others who inherit the code.
- So run linters to check the formatting and readability of code.
- Check for code containing secrets or credentials and mitigate.
- Secure controls of the code - look at the way variables are handled etc...
- Least Privilege in all modules, default deny.
- Compiler Warnings etc...
Build stage you get buildable code from multiple developers. It is important to do vulnerability analysis at this stage. Look at the entire system for vulnerabilities that must be fixed ahead of. Tools like Netsparker, MBSA, etc. fit in here.
- Check for the entire code for Vulnerabilities (don't forget your assess your containers).
- Check for the Open Source Vulnerabilities.
At this stage, the aspect you look for is to also check the third-party code (Open Source code used in your product).
Software Composition Analysis - You could use OWASP Dependency Checker to evaluate and see if you are using any vulnerable third-party components from Open Source and take necessary actions.
Along with testing the feature, you test for vulnerabilities by running penetration testing against the built product (DAST). Tools like OWASP ZAP, Netsparker, Tenable.io etc. can help here.
- Check for potential Vulnerabilities and exploit them - this helps you understand if at all any vulnerability escaped in the previous stages and its impact. Meaning, if leaked what could be potential damage to your client using the product.
- You also evaluate the underlying operating system hardening. You don't want to have a vanilla installation of underlying OS to host your application. That would be inviting trouble. Ensure that your software runs on Operating Systems that is tightened for security.
If you provide the OS bundled, you can harden and give.
If client installs software on OS themselves, then you can provide the guideline to harden the OS.
One could utilize the CIS guidelines to tighten different operating systems.
Shift right comes into the picture. You need to ensure compliance at this stage. Does the built system adhere to general compliance you'd want?
- You could check for security standards (PCI DSS, GDPR, HIPPA etc.).
- Check for protocol compliances (certificates, TLS, etc.)
- Check for code-signing to ensure the binaries are signed by the vendor(your) certificate.
All of these controls can be integrated at the DevOps pipeline itself and it looks like a lot of work and cause a lot of delays as well, right?
Nope, the technology advancement had been so exponential; in fact, we could automate all of these stages. All the stages that we mentioned above could simply be checked for just using a container deployment with the appropriate software. Once built, it just will work and it is all checkpoints (additional stages) in your pipeline. A tool like Jenkins could easily incorporate these with web hooks to these containers and treat them as part of different stages during build.
The next would be continuously testing for security at deployment. As time elapses new vulnerability is identified and your 'secure product' may not be 'secure' anymore. So you wouldn't know unless there is continuous monitoring of the software that is deployed. As and when you identify new issues owing to new vulnerabilities that are identified, you fix them. If we want to be ahead in the game, we need to monitor our software continuously for upcoming vulnerabilities as well.
The reference above is from Microsoft. It depicts the different stages of security controls that should be adopted in the SDLC as we already discussed above.
Here, this is a simple dump, to-the-point explanation of what DevSecOps is & how to implement, without delving much into the theory aspect.
The buzzword is;
SHIFT LEFT &. SHIFT RIGHT