In today’s software landscape, developers push code faster than ever, and security is often overlooked or deprioritized in lieu of faster deployment. This mindset is changing, though, with evolving technologies and risks. As a developer, I am more concerned about whether my logic solves the given problem. With SaaS, where software delivery is faster and software is updated more often, security and risk assessment – that doesn’t slow me down – becomes more important.
Developers are not only using custom code. We write code from scratch, use open source libraries, and get artifacts from software vendors or collaborators. The recent SolarWinds attack and the compromise of the Codecov bash uploader – that went undetected for months – demonstrate the associated risks when security testing of third-party artifacts is not at the forefront.
With software supply chains, one security shortcoming of a vendor or contributor can put all downstream projects at risk. Looking at Codecov specifically, it said the breach allowed the attackers to export information stored in its users’ continuous integration (CI) environments. This information was then sent to a third-party server outside of Codecov’ s infrastructure.
There are multiple examples of attacks resulting in application downtime, cloud resource abuse for cryptomining, fines due to regulatory non-compliance, and damaged business reputation. So, what can an organization do to secure itself, and customers, against these attacks?” This article will tackle the issue of securing the software supply chains against attacks.
Security First Mindset
As developers, we need to have secure coding top-of-mind and follow security best practices during development. Developers must be aware of potential security risks, and the organization’s responsibility is to enable their teams with the tools to handle those risks without missing shipping deadlines or impeding business outcomes. So, developers, must be open to recognizing weak coding practices and press our security teams for ways to find and fix vulnerabilities (e.g. CVEs) in the open source libraries we use to make the software that powers the business.
Organizations need to create a security culture from inception and use automated tools helping teams to move faster and detect security risks before pushing to production., You cannot expect developers to write secure code without enablement, and nobody wants to refactor code the night before a major release. Of course, open source vulnerability scanning tools like Trivy are a big step toward achieving this without creating a burden for the business or delaying security due to long, painful procurement cycles.
But remember: despite developer security education and a security team that uses every application security testing tool available, the software may behave differently in runtime – depending on cloud and infrastructure configurations. This can create potentially unpredicted exploitable conditions in production.
Attack Entry Points Are Everywhere
Today, most of us know the importance of DevSecOps and shift-left security. But so do malicious actors, so they found new and different attack techniques that exploit a trusted software supply chain. That is why least privilege access is essential. If you give access to merge code without review, for example, an internal contributor – or an external actor who gets hold of that account – can push content easily. When this privilege is exploited because of a vulnerability in a third-party artifact or via automated processes in DevOps or CI/CD tools, you become the victim of a supply chain attack.
Maintain Proactive Security Hygiene
Trust should not be a security measure. With this in mind, you need to assess risks in your software supply chain at regular intervals. But, because the software supply chain often prevents direct visibility into security risks in custom code and open source consumed via third-parties, you need a secure way to spin-up artifacts that enter via the software supply chain and detect anomalous or malicious activity that only happens at runtime.
Something like the open source runtime security and forensics tool, Tracee, can help detect threats that only show up when the software is running. When running containers from a public registry, treat the registry as a source with a high risk of supply chain attacks. Attackers are trying to trick developers into inadvertently pulling malicious container images by camouflaging them as popular ones. Create a curated internal registry for base container images and limit who can access public registries. Enact policies that ensure container images are vetted before they are included in the internal registry.
If your supply chain is penetrated despite all of the above, this will ultimately show up as abnormal activity in your production environment. Real-time runtime protection should be an element in any strategy intended to protect against both supply chain attacks as well as “normal” attacks on production infrastructure and applications. Whatever gets detected should be fed into a robust incident management system that provides automated notifications to handle these situations as they arise. For example, if you have a SaaS product, many requests may be coming from the same IP or you may see more requests than anticipated for the resources that have been allocated. If you don’t have any notifications in place for it, you will not be able to restrict or handle the situation in time, which might cause a denial of service due to the burden on your server from a malicious actor.
Of course, the traditional best practices remain important when securing cloud native applications against supply chain attacks. Use a password vault, rotate your secrets or passwords regularly, and minimize your attack surface. AWS Lambda, for example, spins up and remains active for a short duration, reducing the potential impact and chance of exploitation.
Proper software supply chain security, basically, requires a combination of fundamental best practices for secure coding and application security testing, mixed with pre-production runtime testing of compiled software to detect malicious or anomalous activity that static code scanners or software composition analysis will not detect.
You have to start with a “security-first mindset” and enable developers to utilize automation to act quickly and mitigate or address security risks.
Authored by Bhuvan Bhatt, India R&D Head, Aqua Security