Deliver Software Faster with Secure DevSecOps
In the new digital world, businesses are demanding quick release cycles. Teams have started adopting continuous integration and continuous delivery practices along with other agile practices. Let’s see how this is done.
Quality software has been delivered and agile methodologies have been practised for quite a while now, and have helped to build applications faster. At first glance, this probably looks like the perfect setup for delivering certain software. Figure 1 depicts this scenario.
An important question is: should we deliver quality software or secured quality software? Why is security important? Just take a look at the data breaches and hacks. Their number increases every year and the number of records stolen is also huge.
Application security has never been more important and it’s going to get even more focused. So how do we add security in the whole process? Can we do a source code review or carry out penetration testing with an expert? No, these processes will slow us down. This need for automation is what has given birth to DevSecOps.
DevSecOps
Traditionally, security was always an afterthought, done very late in the life cycle with a small set of people involved for a short period. DevSecOps adds a new perspective to security.
■ It brings automation to security
■ Offers faster feedback — developers get feedback as they write the code
■ It uses tools to overcome limited human knowledge
■ Gives continuous feedback, and not a one-time review before release In short, DevSecOps enables software delivery at speed. It is also the new approach to operationalise security. For continuous secure delivery, we need to bring security practices in the earlier stages of software development (shift left approach). To achieve this, we need to focus on the five key things listed in Figure 5.
Awareness: Build a collaborative culture
Awareness is the key problem in the vast landscape of security. The best way to create awareness is build communities and make people talk about the importance of security. A few simple steps can be followed to achieve this:
■ Brainstorm with your security community and experts
■ Identify short-term and long-term goals
■ Build security champions at global and regional levels, and in the office and team to achieve these goals
■ Conduct regular knowledge-sharing sessions
■ Measure improvements across teams and projects regularly
■ Retrospect and repeat
Integrate: Security in the development process
Developers need to think about security during the project development life cycle itself. The first step towards achieving this is to have threat modelling, which is thinking about what can go wrong before it goes wrong so that something can be done to prevent it. ‘A Guide to Threat Modelling for Developers’ by Jim Gumbley is an awesome article on this subject.
Security plugins in IDEs can provide feedback while coding.
There are several plugins available to identify vulnerable dependencies/ libraries, static code analysis, or even for scanning containers.
There are two ways of detecting vulnerabilities in OSS packages:
■ Detect vulnerabilities when you add any dependencies/libraries
■ Scan the whole code base in the background whenever the OSS list is updated
There are several plugins available for this. Figure 7 illustrates the Snyk plugin.
The Snyk plugin for Node.js based projects provides suggestions about whether the library used has any known vulnerabilities or not. This provides faster feedback to the user.
The Grype plugin (Figure 8) scans for vulnerabilities in the libraries in the background — it scans whenever the list of packages used is modified. Similar to the Snyk plugin, it also gives prompt feedback to the developer.
Automate: Security in CI/CD pipelines
Build pipelines are the sweet spot to automate security using tools.
Here, each and every commit can be scanned for security vulnerabilities or misconfiguration. Security tools have evolved over time to detect several bug patterns that might get missed during manual security reviews.
The following things can be automated in the build pipeline:
■ Identification of known vulnerabilities in the application dependencies or libraries
■ Identification of known vulnerabilities in the container images or VM images
■ Identification of OSS licence compliance violations
■ Identification of missing security configurations (secure defaults)
■ Identification of missing compliance and security hardenings
■ Identification of vulnerabilities in the application code -- static code analysis
■ Identification of runtime vulnerabilities -- DAST
Since this is quite a vast topic to cover, we will discuss how we can automate all of the above in my next article.
Protect: Prevent attacks from happening at runtime
After deployment, the application needs to be protected from any unknown threats that could occur. Even if we follow all the above practices, we cannot guarantee that all the security issues are detected. The most common runtime application security protection options are:
■ Web application firewall (WAF)
■ DDoS protection and rate limiting
■ Interactive application security testing (IAST)
■ Runtime application self-protection (RASP)
Monitor: Continuously monitor applications and infrastructure
After deployment, the application needs to be monitored to identify security vulnerabilities and misconfigurations
such as those listed below.
■ Pipelines can help in identifying vulnerabilities, but what if the project is not under active development. How does one detect new vulnerabilities?
■ Vulnerability may be fixed in a code, and reach the production environment.
■ Admins may configure applications directly on the production environment. Who will be auditing those changes for misconfigurations that could lead to security issues?
■ There might be PaaS tools used in the production environment. These tools won’t be scanned as part of the pipeline. How does one audit such security configurations?
To avoid the above problems, we need to monitor applications from a security aspect as well. Again, this is quite a vast topic to cover.
One size doesn’t fit all
Security should be contextual:
The above practices may need some tweaking considering your application’s ecosystem and the team.
Security should be continuous:
Identify a strategy that fits for you. Retrospect often and improve it over time.
Security should be collaborative: Security is everyone’s job now. Collaborate with your delivery, infra and security teams.
Security is a journey, and not a destination: So let me end with my favourite quote: “The journey is what brings us happiness, not the destination,” Dan Millman, Way of the Peaceful Warrior.