CI/CD Pipeline Security - DevSecOps Catalyst

In our previous post comparing Continuous Delivery vs Continuous Deployment, we learned that Continuous Delivery focuses on confidence. With the ever-increasing amount of users trusting our systems, security today is not an afterthought during the SDLC as the DevSecOps movement is teaching us. 

Our applications and platforms continue to grow more distributed and complex yet the velocity or our changes are also increasing. With a widening attack vector, application security is crucial to our organization’s success and the DevSecOps movement is maturing to help provide coverage around the sophisticated attack vectors. 

Security O’Plenty

Security is certainly a big business. As a modern society, we depend on our information infrastructure. As industry moves towards standards and components based development, attackers have a wide attack surface when vulnerabilities are present. Per the recent Microsoft Breach, in 2019 billions of records have been breached. 

Collectively security standards in industry are continuously improving. In the application world. DevSecOps has been preaching shifting left aka moving closer towards the developer. All in a name, similar to DevOps is the merging of development and operations, DevSecOps is the merging of development, security, and operations. Armed with better information and practices, engineers can make better development and maintenance time decisions. 

Like any domain, security can have a lot of terminology. As my responsibilities started to increase and started to look into application security, I had to become familiar with a few new terms. NIST, or the National Institute of Standards and Technology (yes the weights and measures folks) is pretty prominent in cybersecurity. NIST is home to the NVD or the National Vulnerability Database which is one of the golden standards of security information. The NVD hosts CVEs or Common Vulnerabilities and Exposures which are used to publically describe security vulnerabilities. Rounding out the acronyms for places to learn and look is OWASP or the Open Web Application Security Project is an organization that helps to move forward application security practices. OWASP home to the OWASP Top 10 which for software engineers shows common pitfalls and remedies. 

With those main terms out of the way, there have been lots of advancements in security coverage. There are a few categories of tools that will help disseminate information to engineering teams in an automatable fashion.  

Automatable Application Security

Application security has certainly shifted left allowing development teams to continue to improve their security prowess. For organizations moving towards a DevSecOps model, your Continuous Delivery pipeline is a natural area to include security coverage.  Below are a few categories of security-centric technologies that can integrate into a Continuous Delivery pipeline. 

The first is SAST or Static Application Security Testing.  SAST tools typically inspect application code and configuration for known good and bad patterns. Having code coverage is not a new concept in terms of test coverage but more so security can be added into the mix into code coverage / overall quality of an application. OWASP maintains a pretty comprehensive list of SAST tools. An easy example of how a SAST tool can help is for example if you have unsanitized input e.g allowing for some sort of injection a SAST tool can alert you for lack of filtering on an input. I know this because I was the king of unfiltered Web XML’s and our SAST tool would let me know that. 

Moving along in sophistication, code-level analysis can only tell us so much as your application code is part of an ecosystem and environment aka the infrastructure. DAST or Dynamic Application Security Testing. As our applications grow more complex and distributed, ecosystem concerns come into play. A DAST tool will try to perform an exploit on your behalf in a safe and controlled environment. Though a DAST tool will need some sort of deployed application to run through which in theory will catch a problem later in the pipeline but will shake out environmental concerns. 

Dependency and artifact/image scanning tools are popular today and par for the course with open source development. A large emphasis was placed on open source dependency scanning [matching packages to CVEs] after the Equifax Breach in 2017. We certainly don’t stay on projects forever and having the ability to inspect a software bill of material is important knowing what is inside our platforms as that granular tribal knowledge is hard to transfer. 

RASPs or Runtime Application Self Protection platforms are new-ish on the scene. Imagine a RASP as a catch-all for your application security needs as new threats emerge. A RASP is typically a dependency deployed with your application which will analyze calls in and out of the application e.g method calls. Similar to a Web Application Firewall [WAF] deployed on the edge of your network, a RASP will adjust for suspicious calls but unlike a WAF is not limited to HTTP/S. 

The orchestration of several tools are needed since there are best of breed and purpose-built tools that focus on certain areas in your application security stack. A Continuous Delivery pipeline is a great place to orchestrate those tools but how do you go about securing your CD pipeline itself?

What about your actual pipelines?

Years gone by the importance of your pipeline were not there because for most of us a Continuous Delivery pipeline was a concept and not concrete. Fast forward to today, many organizations depend on their Continuous Delivery pipelines to get their ideas into the wild. Typically touching all your environments, security is crucial. 

As any robust piece of application infrastructure, limiting who has access is the first step. By design should be limiting who can execute a pipeline / deploy to a higher environment to those who need to. Giving access for all to see the health of the pipeline is also a radio dial to balance aka the principle of least privilege. This is where role-based access (RBAC) comes in allowing for a successful implementation of least privilege. 

Having the ability to see who and when made changes is an important pillar for many organizations under regulatory requirements. Even if your organization is not under regulatory requirement, the expectation of modern enterprise software is to produce some sort of audit trail so at least we can see who made a change that broke the pipeline.

Clearly most of us [hopefully all of us] are not using passwords in plain text. Leveraging a secret manager not only for credentials that are leveraged in the pipeline but a way to swap out keys, etc as they age is critical. The Harness Platform has a robust secret manager which if you have not used a secrets manager before is an excellent way to jump-start that. Harness is here to help orchestrate confidence across disciplines in your organization. 

Harness - Platform to Build Confidence

The Harness Platform is the platform to orchestrate security steps in your pipeline. As the DevSecOps movement continues to mature, orchestrating the security coverage will become standard for most organizations. 

The Harness Platform has the ability to score conformance to a pipeline standard. This can be very helpful in making sure aspects such as security testing are not brushed under the rug in your pipelines as your organization becomes more mature in DevSecOps practices.  

Feel free to take the Harness continuous delivery platform for a spin today to see how you can include security-centric steps in your pipeline today and acting as a catalyst for your own DevSecOps movement. 

Cheers!

-Ravi