Scanning and securing pipelines

We’re in the age of cybersecurity vulnerability. Security is a multi-faceted and changing speciality, but the first line of defence should lay with those building software from the ground up: It lies with software developers before their product goes into customer organisations.

Improving the security of the continuous integration pipeline is critical as part of the entire infrastructure and application lifecycle. Developers are becoming more autonomous as they move to a DevOps way of working, yet they are not security experts. Likewise, security professionals are not developers. Somehow development teams must learn how to deliver quality applications securely and collaboratively, at pace – because derailing the engineering timeline is not an option. The risks of releasing insecure code only grow larger as the world works collaboratively and interconnectedly, optimising the slack out of global systems of trade and cooperation.

Security checks must not feel like a drag on engineering velocity. A lack of communication between the engineers and developers is often a cause of delay to vulnerabilities being discovered, and unclear responsibilities and can affect the morale of engineers who may feel unable to understand and fix problems in their own code.

Part of the way to collaborative success includes the tools and processes that keep security top of mind, including code and package scanning, and security scanning systems. Automating security testing into existing software development lifecycles and thinking of it just like integration testing is key. It all helps to find and fix issues early and often through CI/CD before vulnerabilities are found or exploited in production or later.

Fully deploying infrastructure and applications through CI/CD means that the whole domain is described in code. This can then be automatically scanned to meet security vulnerability management without undue effort. Implementing security scans in addition to other testing comes in the test phase of build, test, publish. Starting is simple, with free and open-source tools meeting the needs for different types of scans. Plan to implement three overall types: scanning source code, containers, and infrastructure.

Automate security scanning in CI/CD as part of a security package

This should be part of a package that goes beyond scanning. Developers need security tools built for them – Software Composition Analysis (SCA), Static Application Security Testing (SAST), and Dynamic Application Security Testing (DAST). Then, baseline the applications. The development team needs time to address existing software issues and remediate problems. They need trust to do this. Traditional security roles must support with training, setup, and support of tools. And align the organisation behind the shift left. Engineering and security teams must share goals and communicate for success.

All of that said, it’s the automation of security scanning that helps deliver the real magic as part of the security transformation. Post-baselining, link security tools to the build automation (CI/CD) pipeline. That way developers can make code changes which will be automatically scanned. Developers will be altered to concerns and may remediate or block builds as required.

CI/CD pipelines can execute various different tests within the workflow. Static application security and dynamic application security testing are the main pair of common types. Static application security testing scans uncover vulnerabilities early in the pipeline, pre-deployment and production.

Dynamic application security testing will scan deployed infrastructure or applications. Running such scans prevents issues from reaching the production environment, and these scans can run on the production environment. A multi-layering of scans builds a strong defence which can be automated as further risk reduction.

Monitor the CI/CD pipeline itself

The pipeline represents a foundational platform with permission to change further infrastructure and applications. Any vulnerabilities could compromise the entire environment, so monitoring and auditing are best practice to avoid such an occurrence.

Teams should look for non-rotated access keys and too generous access. Monitoring tools will alert and offer insights to mitigate vulnerabilities. Again, automation that can immediately revoke access or disable keys is useful. Use these auditing tools to review any changes to the pipeline itself and implement a process, including automated checks and manual reviews, to protect pipeline quality.

That’s the foundation of the shift left

Layering tests and scans and reviewing the people, processes, and technologies involved, is crucial. Automating removes human fallibility and allows developers to be alerted to vulnerabilities before code is deployed to production. They fix these issues fast. The costs and time taken to find and fix security issues, as well as the risk, is reduced. It’s like running any suite of automated integration tests, but now tests include security, with found failures now in the hands of developers to remediate.

The post Scanning and securing pipelines appeared first on JAXenter.