DevOps and the importance of shift-left security

You’re moving a million miles a minute, adopting new technologies like containers, serverless, and Kubernetes while automating everything under the sun. DevOps has transformed how your teams build, test, and deploy applications. But in your rush to release faster and more frequently, security often gets left in the dust.

New cloud security issues emerge with alarming frequency, and traditional security testing just can’t keep up. You need a way to integrate security practices earlier into your development lifecycle. That’s where shift-left security comes in.

What is shift-left security?

Shift-left security means baking security practices into your DevOps workflow from the start. Instead of taking on scanning and testing after an application is ‘done,’ you shift those left to integrate them continuously throughout development. This might include:

    • Adding security scans and tests into your CI/CD pipeline. As developers check-in new code, changes are automatically scanned and tested for vulnerabilities. Issues can be fixed quickly before they progress too far.

    • Create security test criteria upfront. Define your security requirements during planning stages. Make them as important as functional requirements. Include security testing criteria in user stories.

    • Training developers in secure coding. Invest time in building security knowledge across your teams. Having this baseline allows developers to design more secure code from the start. They don’t have just to wait for the security team to run scans after the fact.

    • Collaborating closely with security teams. Bring security experts into planning conversations with developers. Have them advise on potential risks of new technologies/design decisions used. Promote open dialogue between Sec and Dev.

Shift-left brings security into the conversation early and often. You bake it into your development lifecycle, so it’s no longer just an afterthought before launch.

Why shift-left security matters

You may be thinking, I already do scans during my pipeline. Isn’t that enough? Why does shift-left security matter so much here? There are a few key reasons:

1. It’s greatly cheaper to fix issues early on

It will cost significantly more to fix security vulnerabilities in production than development. Imagine if you can quash an SQL injection vulnerability during code review before it reaches staging environments. The effort and risk involved are minuscule compared to responding to a publicly-disclosed exploit in production. Shift security testing left and eliminate whole classes of flaws before they get costly.

2. Your releases stay on schedule

When you leave security testing for right before launch, any vulnerabilities or failures result in a last-minute scramble. You might have to delay releases to fix or re-test issues. Shift-left practices prevent last-minute surprises so your teams can ship reliably, on schedule.

3. Your developers build more secure code

Developers have the most control over application security. Equip them with skills and feedback to make secure coding second nature. By shifting left into the planning and dev cycle, they can eliminate entire categories of vulnerabilities by default. Your whole codebase becomes more robust.

4. You reduce risk

The earlier you catch security issues in the SDLC, the less exposure and risk they represent for your organisation. Code with flaws that sits in repos or pipelines is much less risky than the same flaws in production. Shifting left shrinks your window of vulnerability over your release process.

5. Cloud environments compound risk

Your cloud infrastructure introduces a whole new set of risks – misconfigured S3 buckets spilling data, overly permissive IAM roles, unpatched compute instances, and so on. Adversaries love exploiting cloud misconfigs as much as application flaws. Shifting left on cloud sec by locking down environments and infrastructure-as-code templates reduces this massively-expanded risk surface.

Making the shift happen

If you buy into the importance of shift-left security, it’s important to remember that the most challenging work lies ahead…actually making organisational shifts happen. Here are some tips on transforming practice:

Start incrementally

Trying to overhaul your entire SDLC overnight is asking for failure. Start small by adding one shift-left practice of continuous scanning for open-source vulnerabilities in code repos. As that gets established, layer on another. Momentum – not perfection – is vital.

Show value early and often

Collect data and stories showing the value of shift-left security. Track defects found and costs avoided. Celebrate developer wins by finding bugs during code review. Promote shift-left ‘rock stars’ publicly. Numbers and narratives inspire change.

Incentivise and support developers

Penalising developers for introducing vulnerabilities and fail builds only discourages transparency about bugs. Instead, reward them for engaging in secure coding practices – budget time for proper training and set goals around security KPIs.

Integrate security into processes

Require security reviews for new technologies and frameworks. Add mandatory security criteria to project planning documentation. Work it into sprint demos and retrospectives. Process integration drives consistent behaviour versus leaving it up to people’s choice.

Accept increased feedback cycles

Yes, shift-left testing will raise more defects and delays early on. Teams may seem ‘slowed down’ by extra security criteria. However, take the long view – this feedback helps get more resilient code deployed safely at scale later.

Locking down your cloud environment

We’ve talked a lot about practices in your pipelines and SDLC. But it’s just as crucial to lock down the cloud environment your apps run on. Misconfigurations in cloud infrastructure like Kubernetes, serverless functions, and object storage can introduce security risks like code-level flaws. Here are some quick cloud best practices:

    • Encrypt data at rest and in transit – don’t rely only on physical data centre protections.

    • Segment development, test, and production environments. Limit data and access to prod.

    • Use tools that check for misconfigured infrastructure as code (IaC) templates. The majority of cloud breaches involve misconfigured IaC.

    • Follow the principle of least privilege – only give users minimal permissions needed vs widespread access.

    • Monitor user activity and changes made in your cloud environment,

    • Enable advanced features like container image signing to prevent untrusted images from running.

Remember, adversaries focus on exploiting cloud misconfigurations as much as code-level flaws. Lock it down tight across infrastructure and codebase.

Final Word

Shifting security left may feel uncomfortable at first. Developers will have to think about threat models and vulnerabilities in addition to product requirements. Releases might seem ‘slowed down’ by extra testing. However, stick with these practices for long-term information security wins.