Select Page

Vardhan NS

last updated on November 9, 2023

Time and again we have witnessed hackers use a software’s supply chain to take advantage of exposures  and sneak into its systems and wreak havoc. There are many such instances where exposures have gone undetected for months or even years altogether. Most notably – The Solarwinds Orion attack (also called Solarwinds supply chain attack) that went undetected for 14 months from Sep. of 2019 through to Dec. of 2020. 

Notable Hacks/ Attacks from the past

While it was initially reported that a stagerring 18,000 customers applied the Sunburst update, Solarwinds later corrected that only 100 companies were hacked. Among notable victims, 20% of the attack was on government agencies, including the US departments of health, treasury, and state. The remaining 80% of victims that were private corporations, included big players in their industry with their fair share of high-profile clients. The hack affected companies like Cisco, Intel, Deloitte, and Microsoft, as well as some medical institutions, hospitals, and universities.

While this is just one example, there are countless other organizations that have suffered because of vulnerabilities/ exposures in their software supply chain, specifically relating to software deployment/ software delivery. Target (2013), Equifax (2017), Log4J (2021), Kaseya (2021), and Codecov (2020), are some notable examples of CVEs arising from a lack of security measures in their software delivery chain. 

If you are bewildered by the various terminologies/ concepts discussed thus far, then let me get down to the basics and clarify some of the terms/ concepts before we go further. This will help you relate to the rest of the contents of this blog. 

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures

Vulnerability is a weakness in a system – something that has the potential for being exploited. Vulnerabilities can allow attackers to run code, access system memory, install different types of malware and steal, destroy or modify sensitive data.

However, an Exposure is a known incident in which the vulnerability was acted upon. It is a mistake that gives an attacker access to a system or network.

What is a supply chain attack?

A Supply Chain Attack is a cyber-attack with an intention to damage an organization’s reputation by targeting the less secure elements in their software supply chain. Typically, a supply chain attack is carried out by targeting an organization’s (software) suppliers as a means to gain unauthorized access to that organization’s systems or data. They’re sometimes also called value chain or third-party software attacks. 

Having questions around enabling DevSecOps or securing Software Deliveries?

Typically, supply chain attacks seek to gain access by implanting a backdoor into products, typically software, used by the target organizations. This allows the attackers to deliver automated patches or “trojanized” software updates that open the door for malware and other attacks. In the case of the Solarwinds hack, the attack was in the form of a routine software update.

Why should organizations put an effort into enhancing Security?

Besides the reasons and examples explained above, in most major breaches, the impact is never really restricted to the breached environment (that includes internal systems, employees, and its finances). The impact almost always extends to its clients/ customers. And what takes the biggest hit in such cases? Trust, branding and reputation! Which inturn disarms them from onboarding new and big enterprises, let alone retain the existing one’s.

It is estimated that 70% of business applications used by companies today are SaaS-based. It is also estimated that this SaaS adoption will grow to 85% by 2025. Another independent research by BetterCloud, states that a company with an employee count of 500 to 999, uses about 93 different SaaS applications, with that number rising to 177 for companies with over 1,000 employees.

From this, it is clear that we live in a world where organizations are inter-connected by the underlying software (or SaaS these days). So it is absolutely imperative that the software powering us in our day-to-day is secure and trust-worthy. But given how impressive and innovative contemporary Attack Vectors are, extra care should be given to fool-proof software delivery/ deployment. Look at the table below to understand the different attack vectors and the stage during when they are incubated.

OpsMx Capability Score

The data from the above table coupled with the historical evidence of hacks all over the world clearly indicate that Threat Actors target the build and delivery/ deployment tools of the software supply chain in order to exploit vulnerabilities and exposures. 

While software vulnerabilities can also be caused by factors such as coding errors, poor design, and the use of outdated or insecure software, the most prominent cause is the use of/ introduction of third-party libraries or components that have not been properly vetted for security.

So, how do you Secure your Software Delivery?

The answer is pretty simple. You need to leverage a tool that: 

  1. Constantly monitors your deployment and tracks vulnerabilities 
  2. Automatically assesses risks and enforces organization/ industry specific policies 
  3. Integrates seamlessly with your existing DevOps & DevSecOps toolchain 
  4. Enhances your overall security posture 

In short, you need a Deployment Firewall!

Securing Software Delivery with OpsMx’s Deployment Firewall

As the name suggests, our Deployment Firewall is analogous to an actual Network Firewall. In short, it provides a gating mechanism for your existing CI/CD tools to prevent security vulnerabilities from going to staging or production. Being the last line of defense, the Deployment Firewall enforces Security, ensures Code Quality, and regulatory Compliance practices – all within the CI/CD platform.

The Deployment Firewall - what is it & how does it work?

The Deployment Firewall (an integral feature of OpsMx Secure Software Delivery) is governed by a comprehensive set of firewall rules (mostly prepackaged) with an ability for the end user to create new rules, redefine and reconfigure as per the need. The goal of the Deployment Firewall is to perform real-time checks during delivery time so as to determine if the software delivery meets the pre-defined firewall rules or not. 

By checking for broken rules or policy violation flags, and by deriving the Delivery Bill of Materials (DBOM), the decision to deploy or not will not only get automated, but also ensures that the applications deployed are secured and 100% compliant.

SSD with OpsMx Firewall

Here are a few examples of the Deployment Firewall rules:

  1. Does this deployment or Artifacts associated with this deployment have any critical CVEs? 
  2. Will this deployment introduce any recently reported CVE into the environment? 
  3. Do we have adequate unit test coverage?
  4. Is the quality code meet approved by DAST and SAST? 

Another very popular use case of the Deployment Firewall is when a vulnerability is newly reported, you can enforce a real time rule to stop all deployments containing the affected packages/ artifacts.

Deployment Firewall is when a vulnerability report

Securing Software Delivery with OpsMx’s Deployment Firewall

Just to summarize what I’ve explained so far, the Deployment Firewall makes the last mile checks (in real time) to make sure that the deployment is in full compliance with the configured deployment rules. And to power this process, there are 3 distinct elements to it: 

1. Admin layer 

  1. This is the UI layer where you (or users) can manage and configure the firewall rules 
  2. This layer is typically where all the data/ information is ultimately defined 

2. Intelligence layer 

  1. This layer makes up the core of the Deployment Firewall engine 
  2. It compares the defined rules against actual instrumentation data coming in from other DevOps/ Security tools 
  3. It is the combination of the rules configured in Admin layer and data collected from other DevOps integrations, that checks if any critical CVE is present
3. Enforcement layer 
  1. As the name suggests, this is the enforcement layer which checks if the deployment is in 100% compliance and there are no broken rules
  2. It checks for open violations and blocks deployment. In addition, it notifies concerned personnel about the blocked deployment 
  3. It also allows you to manage exceptions in case deployment needs to happen with a warning.
OpsMx delivery intelligence


Deployment Firewall is one of the key capabilities to implement DevSecOps. It prevents security vulnerabilities and compliance issues from going to the staging or the production. 

Please visit Secure Software Delivery for overall DevSecOps capabilities or request a detailed demonstration of Deployment Firewall.

About OpsMx

Founded with the vision of “delivering software without human intervention,” OpsMx enables customers to transform and automate their software delivery processes. OpsMx builds on open-source Spinnaker and Argo with services and software that helps DevOps teams SHIP BETTER SOFTWARE FASTER.

Vardhan NS

Vardhan is a technologist and a marketing professional, currently working as a Sr. PMM at OpsMx. His strength lies in understanding complex technologies, and explaining them in un-complicated ways. Vardhan is a passionate Product Marketer with a keen focus on Content, helping brands Position themselves uniquely with clear messaging and competitive differentiation. Outside of work, he is an athlete that is passionate about Football, Swimming and Surfing.



Submit a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.