Application security: shift-left is necessary but insufficent

Integrating security checks into code should be seen as part of a bigger picture, says Kubecon panel

Shift-left, aka DevSecOps, the practice of making security checks part of the software development lifecycle rather than being a separate (and slow) step at the end, is essential for agile development now that perimeter protections are long gone and the emphasis is on speed of iteration, but it should be an addition to existing security checks and not a replacement for them.

So said a panel of application security specialists at the Cloud Native Computing Foundation (CNCF) KubeCon & CloudNativeCon Europe event yesterday.

Panellists discussed DevSecOps in practice, incoming requirements such as Software Bill of Materials (SBOM), and aligning the incentives to secure code.

With the shift-left approach seeing much responsibility for security devolved to developers and platform teams, is there a danger that expertise could be spread too thin, the panel was asked.

Not if you follow the principles of strength-in-depth, said Liz Rice, author, chief open source officer at security firm Isovalent and CNCF TOC emeritus chair. It's a matter of having the right tools in place to cover scanning, signing, runtime protections and the rest, and to apply them at different stages of the SDLC and to the various different infrastructure layers, she said.

"You don't just have one layer, you have lots of thin security layers that build up into a thick layer."

Gaurav Rishi, VP of product and partnerships at Kasten by Veeam, said that ensuring developers consider basic best practice can be a challenge, because "no-one likes going through a checklist".

To ensure backups and data protection requirements are taken care of, automation is required, which is why terms like ‘policy-as-code' are entering the DevOps vocabulary. "When a cluster is spun up it becomes an automated piece to ensure any new application in the cluster starts getting protected."

Because of the vast number of vulnerabilities in complex applications, their dependencies and underlying infrastructure, DevSecOps teams cannot hope to tackle every one - they would be overwhelmed. Therefore, they should prioritise them in the context of the particular application, giving each glitch a score to each based on potential impact and risk, suggested Andrew Martin, CEO of cloud native security consultancy Control Pane.

"That allows you to have a quantifiable view as to where you place your security controls and where ultimately value is delivered to the organisation."

Software Bill of Materials

The Kaseya and SolarWinds attacks have bushed home the vulnerability of the software supply chain attacks, with suppliers to US federal organisations to be required to provide a Software Bill of Materials (SBOM) for their projects, listing all the components involved.

This is much easier said than done, said Owen Garrett, head of products and community at cloud native observability firm Deepfence.

"The automotive industry is very good at maintaining inventories of what went into the vehicle in case of recall, and the hope is we can do the same for software. But the reality is, it's very, very difficult to maintain an accurate BOM across the entire infrastructure."

This is because each third party add-on has its own dependencies and components, and the overall situation is one of constant flux. Nevertheless, it is certainly valuable to keep track of where core libraries are located and to track changes in those, he went on.

"It's by no means a single method of protection, but it provides a good baseline, so when something like Log4J happens you've at least got a starting point to identify where the vulnerabilities might be."

The Open Source Software Foundation (OpenSFF) recently created a project called Alpha-Omega to improve supply chain security, targeting and evaluating the most critical open source projects to help them improve their security postures. It's early days, but the project is backed by heavyweights like Google and Microsoft, and panellists were hopeful it will focus attention at the very least.

"As consumers of open source code, we need to return some of the value we derive from it to source and sponsor," said Martin. "Hopefully things like Alpha-Omega will move the needle."

Incentivising security

Unfortunately, the imperatives of security and development often tend to pull in different directions, and developers need to be better incentivised to integrate security practices into their work.

"What motivates developers is getting things done," noted Garrett, "A lot of developers don't have the global perspective or, or even the maturity in the industry to take security as anything other than just an impediment to getting the job done."

There need to be default guardrails, but there should also be secure ways for developers to request exceptions, so they can go beyond the guardrails when they need to without creating unnecessary risk.

The incentives also need rebalancing, Rice said: "It's very striking that we give hackers measurable rewards for finding vulnerabilities in bug bounties and so on, but I haven't seen anything around the next step - rewarding people for fixing them."

Join us at the CyberSecurity Festival 2022, taking place across 3 days in June, where we will come together to learn, collaborate and tackle the biggest technology security challenges. Find out more and register for free