Security defined as code: Leveraging IaC can make supply chains resilient

 Over a year since the SolarWinds hack took governments and enterprises by storm, building cyber resilient systems has become a top priority for organizations across the world. As cloud-native-technologies use numerous third-party softwares, supply chain vulnerabilities are now a common vector cybercriminals leverage for attacks. Legacy cloud security technologies have always been deployed after the software is developed, when fixing the issues becomes too expensive. Using Infrastructure as Code, organizations can ensure that security evolves at the speed of the cloud. In today’s hyper-digital world, security needs to be built into the DNA of the software — the code itself. Automated tools that identify vulnerabilities and misconfigurations at the time of writing the code, are not only developer-friendly, but also makes software secure by design. Security as Code is a proactive approach to cybersecurity, which will make systems and networks more resilient to attacks. Piyush Sharrma, VP of Engineering, Tenable, in an exclusive interview shares more insights about why security defined as code is the key to building resilient software.


  1. How can Security-as-Code combat cyber threats in the software supply chain?

Most applications that enterprises use may contain code that the IT teams didn’t write especially if they’re using libraries from open source. Vulnerabilities and cloud misconfigurations in third-party or open-source dependencies, pose significant security risks. Because if one of these dependencies has a vulnerability, then chances are the organization using the code is vulnerable as well.

Security teams have very little control over vulnerabilities that exist in the application and environment that they are responsible for protecting. Vulnerabilities, for the most part, are introduced into the portfolio by developers, and developers are the ones that remove vulnerabilities by implementing code changes. When the security team finds a vulnerability that needs to be fixed, they first need to convince a developer that (a) it really is a vulnerability, (b) it really needs to be fixed, and (c) it really needs to be fixed now. Then they probably need to help determine how best to fix it, because most developers are not security experts. That’s a lot of work, multiplied by a lot of potential vulnerabilities.

Security-as-code is the practice of embedding security into DevOps tools and workflows by mapping out how changes to code and infrastructure are made and finding places to add security checks, tests, and gates.

Assuming security as code tools analogous to those used for Infrastructure as code are available, teams could leverage those to enforce compliance to the codified goals throughout the development process, ensuring continuous compliance and eliminating all meaningful security risks before applications are ever deployed. The codified goals could even follow the application into the runtime environment to provide for enforcement at runtime as well.


2. Why must cybersecurity evolve at the speed of the cloud?

When business continuity is tied to cyber resilience, organizations cannot ignore the importance of taking a security-first approach to codifying how infrastructure should be configured. Traditional modes of securing software are not enough to detect and prevent a breach, because software development and delivery have inherently changed with the move to the cloud and codification of cloud governance. Because by the time software reaches runtime, it’s already too late. The detection of cloud misconfigurations needs to move from reactive to proactive so that security teams don’t have to wait for infrastructure to be created in order for them to discover and mitigate vulnerabilities in code.


3. Cybersecurity strategies that Indian organizations can adopt to protect software supply chains

Supply chain attacks have become very common over the years. Just consider the impact of the Solarwinds attack which is one of the largest to date. With these types of cyberattacks rapidly increasing year over year, security teams and vendors are focusing on them too. So, yes, this could have been prevented by implementing security into the developer build process – continuous integration and continuous delivery (CI/CD) and DevOps Pipelines.

These build processes depend on rapid commits and deployment and with security traditionally being implemented at the end of the process, it’s too late to detect and remediate an attack. Organizations need to establish Infrastructure-as-Code as a common vocabulary between DevOps and security teams, improving collaboration and enabling devops teams to satisfy security requirements independently. They need developer-first security solutions that are compatible with their workflows and detect and resolve vulnerabilities introduced in their build pipelines before cloud applications are deployed.


4. How can CISOs quantify and translate cyber risks in the cloud into KPIs for strategic decision support?

Companies are trying to ensure all critical/high violations are detected and resolved in a timely manner.  This is why the two keys for measuring cloud infrastructure vulnerabilities should be mean time to detection (MTTD) and mean time to remediation (MTTR).  MTTD is a KPI for the amount of time it takes a security team to discover a vulnerability, while MTTR is the time is takes a security team to remediate the issue.

Cloud Security Posture Management (CSPM) solutions are especially great for MTTD as they provide visibility and detection of vulnerabilities for production cloud environments. This however, leads to modernization of CSPMs in that organizations need to be able to continuously prevent and protect against vulnerabilities. Finding the issues aren’t enough anymore. CSPM solutions need to evolve shift left capabilities to proactively prevent and remediate vulnerabilities. When security risks are detected and remediated in the development phase, security teams reduce both security cost and mean time to remediation (MTTR). Having a low MTTR is a key to ensuring an organization’s attack surface is kept to a minimum, which results in better protection against cloud threats.

The cloud-based breaches that have succeeded are mostly due to developer misconfigurations that go undetected and are available for a long period of time for bad actors to discover and exploit. For organizations that only rely on runtime-based security, they will often have a relatively high MTTR as their risks are only discovered and addressed once the technology stack is deployed or in use. This is time consuming and costly. But if security issues are detected early in the cloud development phase and remediated, security issues can easily be remediated and the result will be a low MTTD and MTTR.


5. Cloud applications are at risk of server-side attacks. What are some of the most pressing concerns with cloud apps that make them vulnerable?

Cybercriminals are constantly researching to find fresh vulnerabilities in web interfaces and APIs. Attackers mostly focus on searching for vulnerabilities within web app software like WordPress, Drupal and others. Since these applications are used as supply chain components for building cloud apps, there is an added risk of unpatched vulnerabilities. Bad actors leverage these vulnerabilities and expand their attack surface as the cloud apps inherit vulnerabilities from off-the-shelf software.

Many cloud apps also leverage open-source interfaces. Cloud apps built using these technologies need to be secured at the design and development phase, otherwise, they can be vulnerable to server-side request forgery. Cybercriminals most often leverage known vulnerabilities.

Leave a Response