Runtime Security: Relevancy Is What Counts
Security experts as well as many — if not most — developers and software engineers know that an organization deploying software is almost inevitably working with insecure code. Code and applications are often rife with vulnerabilities throughout the CI/CD process. Other stakeholders, such as the CTO, might have at least some inkling of the status quo but they may or may not know the severity or the magnitude of vulnerabilities and how software even at runtime can be rife with vulnerabilities.
Security best practices have emerged, including those for cloud native deployments. However, that remains a work in progress. Typically, SBOMs and signatures and other security best practices continue to improve. However, detecting and remediating vulnerabilities in code and applications that are deployed remains a work in process. Intuitively, it may seem rational to rely on a common vulnerability scoring system (CVSS) to prioritize the severity of vulnerabilities. This helps to somewhat reduce the whack-a-mole approach to detecting and removing vulnerabilities throughout CI/CD and during deployment. However, this too, can fall short.
This is where a different approach appears more applicable and relevant and of course time-saving. When also combined with automation this process evolves relevancy defined in part as severe vulnerabilities that will remain in the container and code during runtime. The trick is, of course, to automate the pinpointing of these vulnerabilities and which ones are the most relevant, based on the overlap of their severity, flexibility and especially, relevancy.
Prioritization
Ideally, vulnerabilities would be prioritized by the likelihood and severity of future revenue impact — which is similar to how traditional project management is prioritized, Torsten Volk, an analyst for Enterprise Management Associates (EMA), said. A container might include a Python library infected with ransomware, but Volk said this could be irrelevant if:
- The application code running in this container does not actually use the infected library.
- Strict container networking policies block malware from accessing the ports.
- The container runs on a Kubernetes cluster without access to the types of data sources targeted by the malware program.
- The malware needs access to a highly privileged account to be able to spread, while the container runs a bare-bones account that lacks the required privileges.
- The container does have access to a vulnerable data source, but the data source only contains cafeteria menus and the score sheets of the corporate software team.
“Even these few examples demonstrate that a successful attack heavily depends on the context of its target,” Volk said. “However, identifying the relevant context factors and prioritizing vulnerabilities accordingly is where the magic lies.”
It is also important to take into account that Kubernetes is still a relatively young and fast-evolving technology, Oshrat Nir head of product marketing, ARMO told The New Stack. “While it has started to plateau the talent gap still exists. Pairing that with the current macroeconomic climate means that DevOps or platform teams are and will continue to be short-staffed, yet they have more jobs to be done than ever before,” Nir told The New Stack. “As a result, prioritization has become more important than ever.
This goes double for security, Nir said: “A major security breach can taint an organization’s reputation for a long time, making the hit to the bottom line something that takes longer to repair than the breach itself.”
Relevancy
Kubernetes security tool provider ARMO says it has released under beta a new capability with eBPF: vulnerabilities relevancy and prioritization. Relevancy and prioritization allow ARMO Platform and Kubescape users to deprioritize vulnerabilities that belong to unused software packages and components. By first deprioritizing vulnerabilities that are less critical, users can focus on addressing the ones that pose a greater threat to their running cluster.
This release is also important given that, on average, it takes weeks or even longer to apply fixes to security. “As a result, it would behoove DevSecOps practitioners to fix the vulnerabilities that expose them the most first. The problem is that most scanners return a (long) list of vulnerabilities to the users with little to no indication of what to fix first,” Nir said. “This will often leave teams paralyzed and planning the work of patching, testing and deploying the patch can take weeks.”
The typical way of sorting through vulnerabilities is their criticality, Nir explained. “The thing is that many software packages in containers aren’t even used at runtime, which means they pose less risk than their criticality would lead us to believe. This goes double now that hackers, knowing about this best practice, actually try to infiltrate with the more innocuous, less critical vulnerabilities, Nir said.
ARMO’s relevancy feature pinpoints the vulnerabilities that should be prioritized to be fixed, Nir said. “While it includes fixability, criticality and the ability to access the vulnerability remotely (i.e. code injection or remote code execution) it also factors in whether the security packages are actually in use,” Nir said. “In this way, security teams can filter 60%-80% of vulnerabilities out of their immediate to-do list and focus on the things that need to be solved first.”
