CI/CD series - Synopsys: Where does security fit into CI/CD?
This is a guest post for the Computer Weekly Developer Network in our Continuous Integration (CI) & Continuous Delivery (CD) series.
This contribution is written by Meera Rao in her capacity as a senior principal consultant at Synopsys — the company is known for its work in silicon chip design, verification, IP integration and application security.
CI/CD is all about speed, repetition and automation, but where does security fit into the equation? Let’s have a look at some of the application security testing tools that you need to consider in the CI/CD pipeline.
Static analysis (SAST) — SAST tools examine an application’s code or binary without executing the application. Lightweight, desktop options flag common vulnerabilities and offer remediation guidance in real-time as developers write code. More in-depth assessments consider business logic and provide full path coverage, ensuring every line of code and potential execution are tested.
Software composition analysis (SCA) — SCA tools provide a complete view of the software supply chain by analysing open source code, third-party application components and binaries.
Fuzz testing simulates real-life attack patterns used by hackers and automatically bombards a system with malformed inputs. These tools allow development teams to uncover misuse cases that trigger hidden, unknown vulnerabilities and failure modes.
Let’s also mention Dynamic Analysis (DAST) — DAST tools use penetration testing techniques to identify security vulnerabilities while applications are running. We also have Interactive application security testing (IAST) — IAST is an emerging technology that finds real security vulnerabilities in web applications and web services with a high-level of accuracy.
CI/CD security best practices
Now that we’re all up-to-date on the types of tooling options available, let’s examine the best practices for implementing security into the CI/CD pipeline. Treat security issues with the same importance as quality issues. Ignoring bugs won’t make them go away. Instead of waiting to fix bugs and vulnerabilities until after they wreak havoc on your applications, treat them like any other bug within your development process.
Facilitate collaborative change. Organisations seeking to increase developer productivity and solution time to market don’t realise that changes are required by everyone — the business included.
Just like continuous testing, there also needs to be continuous collaboration across development, security, operations teams and business included. Reduce friction between development, operations and security teams.
Carefully choose tools for automation. The rapid shift to CI/CD and DevOps continues to drive the need for automation and continuous testing. Building automated tests is a complex process that requires expertise, it can’t be easily simplified by just acquiring the tools required for automation. Most types of testing can be automated, but automation does not eliminate the need for manual testing.
In terms of security practices to avoid with CI/CD. There are also some highly impactful not-to-do aspects to consider when infusing security into your CI/CD pipeline. Automated tools aren’t a catch-all solution. Tools cannot interpret results for you, nor can they certify that the application is free of defects. You need an expert to determine if the results are true positives. Additionally, an automated tool cannot find new bugs or vulnerabilities. On top of automation and continuous testing, you need to make sure intelligence is built into the CI/CD or DevOps pipeline to know when human intervention is required. Recognise also that tools need hand-holding and aren’t ever truly plug-and-play.
Don’t jump the tracks
A mature organisation fails the build if the security tests don’t pass. If security issues appear in the build (perhaps issues higher than medium severity) the build fails and the development team is notified. Thus, security is treated with the same level of importance as business requirements.
No tool is one-size-fits-all. Organisations use different languages. Different languages mean different build tools. Even when they use one language, teams use different versions of that language which is very common.
Applications use different technologies. An enterprise application might be using different architecture. An application might be using several different frameworks. So, using the same rules and not customising the tool is a recipe for failure.
Summing it up. There are seemingly endless tooling options that can be applied within the software development life cycle and CI/CD processes. The most mature firms apply security mechanisms throughout the development process to ensure that the software that powers their business, the software they’re building to advance their business, and the software customers depend on is secure and continuously improving.
