DevSecOps is another buzzword that many contracts are now seeking knowledge of and experience in. We have also heard about ‘shifting-left’ on security and how this is great to implement into our development teams right? There are 2 reasons that this intention alone may not work to make your applications more secure:
The DevSecOps culture is bringing more of the security checks into your team early so less gets flagged on a pen-test, or even worse in a production security incident. So how can we make adopting DevSecOps culture in our teams a success?
There are 3 main areas for developers to understand and implement automated security checks against:
1. Static Application Security Testing (SAST)
Many of you are already doing static code checks via linters or tools like SonarQube. Explicitly configuring these tools to address security is super important. SonarQube for example allows you setup and tune security rules in your code analysis to make sure that any potential vulnerabilities in the code that you write are flagged. Dependency scanning tools such as NPM Audit or Dependabot make sure the versions of software you use are safe and have no known security vulnerabilities. These checks are great to have in your pipeline and run at intervals, ideally nightly, as new vulnerabilities appear at any time and should be acted on immediately.
2. Configuration scanning of Infrastructure as Code(IAC) and containers
Arguably still part of SAST, but I want to call this out explicitly. Most DevOps teams create their infrastructure using IAC and utilise containers. It is so easy for code to accidentally leave sensitive network access open to the outside world or to allow resources to be run with over-privileged permissions. Tools such as ‘Snyk’ or ‘Checkov’ are great to use for this.
3. Dynamic Application Security Testing (DAST)
When we want to simulate much of what may occur in a pen-test, DAST can be used. Please be clear, it will not completely replace a proper penetration test. However, it can detect some of the common failures and issues that may get flagged in a pen-test. Tools like ‘OWASP ZAP’ or ‘Snyk’ have such DAST capabilities that can be automated and placed in your pipeline. Although not strictly ‘black-box’, as you know the code contents, these tests are an outside-in simulation of ways in which attackers might use OWASP Top 10 security risks and beyond to try and gain unauthorised access to your resources. As this runs against a working instance of your app, it will take more time and effort, and investment to get it working and consistently maintained. Thinking about test data, environments, and how often they are run will also be a consideration.
Doing the above will certainly help but doesn’t assure complete protection. Other considerations should be added to your team’s practices such as; Risk assessments and Security code reviews. Access Control Testing is helpful to test that no one with access can do something more than they are allowed. Encryption testing will help to make sure data has been encrypted to the level you expect. So take time and make discussing the points above part of your team culture and see how much of this can be placed in your pipelines.
Go forth, and be safe!