devopsy.kinsta.cloud

Tag: vulnerabilities

Sonar Adds AI Tools to Identify Issues and Fix Code Created by Machines and Humans

Sonar, in addition to adding generative artificial intelligence (AI) capabilities to its core platform for remediation vulnerabilities, also unveiled a tool that identifies vulnerabilities in code generated by artificial intelligence (AI) platforms.

AI Code Assurance makes use of the core engine Sonar, developed for analyzing code to surface issues in code generated by platforms such as Chat GPT.

At the same time, Sonar is adding AI CodeFix, a tool that invokes large language models (LLMs) to surface recommendations for improving code that development teams approve before being automatically applied.

Sonar CEO Tariq Shaukat said both tools, when involved via either the SonarQube and SonarCloud platform collectively, will improve the overall quality of code, regardless of whether a machine or a human developer created it.

Specifically, AI Code Assurance is now available on SonarQube and will be generally available in SonarCloud by the end of October. AI CodeFix is available for early access in SonarQube Enterprise Edition, SonarQube Data Center Edition, and SonarCloud Team and Enterprise plans.

There have already been instances where code generated by machines has led to outages that have been traced back to code written by generative AI platforms. Those platforms were trained using code samples of varying quality from across the web. It’s not uncommon for the code generated by those platforms to be flawed in one way or another, including the incorporation of known vulnerabilities.

Too many developers, instead of scanning and reviewing that code, tend to put too much faith in the output generated by those platforms, noted Shaukat. AI Code Assurance provides DevSecOps teams with a tool for discovering those issues in a way that can be inserted into existing DevSecOps workflows, he added. Code that has been reviewed by AI Code Assurance is assigned a badge that certifies it has already passed a set of rigorous tests.

Ultimately, that capability should also boost the confidence of senior leaders of application development teams in those platforms, because the code generated is being reviewed before it is added to a build, noted Shaukat.

Thanks to the rise of generative artificial intelligence (GenAI), the volume of code that needs to be scanned will likely exponentially increase. It’s not clear whether the code generated is any more or less secure than the code developed by human developers, who often lack cybersecurity expertise themselves. Regardless of how the code was created, however, no one will know for sure how secure it is without scanning it first. In effect, Sonar is applying AI to fix code generated by AI platforms using a platform that is already employed by more than seven million developers working for organizations such as the Department of Defense, Microsoft, NASA, MasterCard, Siemens and T-Mobile.

The challenge, as always, is making sure the scan runs in an era where developers often either forget to analyze code or can’t be bothered. Whether those developers like it or not, however, when it’s later determined that the code they or a machine wrote is the root cause of cybersecurity incidents, it will quickly become everyone’s problem.

October 3, 2024
JFrog Extends GitHub Alliance to Provide Unified Dashboard

JFrog and GitHub today extended their alliance to provide a unified dashboard that makes it simpler to track and prioritize vulnerabilities from source code to the binaries that are ultimately deployed.

Announced at the JFrog swampUP 2024 conference, the dashboard will make it possible for DevOps teams to bi-directionally navigate from a GitHub Actions Workflows to where, for example, software packages are housed in a JFrog Artifactory repository, including tracking results of security scans, permissions and identities.

That bidirectional integration also extends to software bill of materials (SBOM) packages to make tracking software provenance and dependencies simpler.

In addition, a Job summary page on GitHub provides an at-a-glance view of the health and security status of each project.

Finally, the two companies are providing single-sign-on capabilities enabled by support for the OpenID Connect (OIDC) framework. Previously, switching between development environments required the usage of tokens that could be more easily compromised.

JFrog CTO Yoav Landman said this single pane of glass view of a DevSecOps workflow is the latest in a series of integrations that the two companies plan to simplify project mapping. JFrog and GitHub earlier this year announced a broad alliance that began with integrations with GitHub Copilot, the generative artificial intelligence (AI) framework that is based on large language models (LLMs) developed by OpenAI. JFrog is now also participating in the GitHub Copilot Extensions program enabling developers to use a chat feature to retrieve answers to common coding questions relevant to their JFrog and GitHub environments.

Those integrations are critical because they enable organizations to proactively address compliance requirements that are only going to become more stringent in the months and years ahead, noted Landman. Developers, for example, will be able to eliminate many of these issues as they write code, as opposed to being asked to address issues much later when they have lost the original context for how a vulnerability was created, he added.

It’s not clear to what degree organizations are embracing the best DevSecOps workflows to address this issue. Unfortunately, a recent JFrog survey found only slightly more than half of organizations are using both source code and binary scanning to secure their software supply chains.

However, there will come a day soon when deploying software without scanning for vulnerabilities is likely to be considered a form of negligence, noted Landman.

Hopefully, generative AI tools such as GitHub Copilot should make it easier to discover and remediate vulnerabilities sooner. Addressing those issues should eventually become a part of any quality assurance testing process.

In the meantime, software engineers are being tasked with addressing application security issues before they become a much larger issue for overwhelmed cybersecurity teams that are generally unable to remediate vulnerabilities without the help of an application developer. As such, the better part of valor is to eliminate as many of these issues as possible, long before code ever makes it into a production environment.

September 10, 2024
Report Surfaces Thousands of Potential Vulnerabilities in GitHub Workflows

An analysis of 2.5 million GitHub Actions workflow files belonging to 553,000 organizations and personal users published today suggests many DevSecOps teams that use the GitHub continuous integration/continuous deliver (CI/CD) platform to build and deploy applications are relying on workflows that are often fundamentally insecure.

Published by Legit Security, a provider of a platform for managing application security posture, the report uncovered interpolation of untrusted input in more than 7,000 workflows; execution of untrusted code in over 2,500 workflows; and use of untrustworthy artifacts in 3,000-plus workflows.

Additionally, 98% of references used by jobs and steps do not follow the best practice of dependency pinning while 86% of workflows do not limit token permissions.

Many of the actions created by third parties that DevOps teams might reuse are also insecure, mainly because they have been created by small teams that lack cybersecurity expertise. Of the 19,113 custom GitHub Actions in the marketplace, only 913 were created by verified GitHub users, with 18% having vulnerable dependencies. A total of 762 are archived and do not receive regular updates.

Noam Dotan, a security researcher for Legit Security, said that it’s apparent there is still much work to be done securing software supply chains that cybercriminals are increasingly focused on compromising in hopes of injecting malware into multiple downstream applications. While there is not much a DevSecOps team can do about a vulnerability found in the core of a CI/CD platform, there is plenty of opportunity to remediate DevOps workflows at the application level, he added.

For example, many DevOps teams are employing workflows that have risky dependencies or provide overly permissive access privileges that create vulnerabilities that should be addressed before they are easily exploited, noted Dotan.

The Need to Make Software Supply Chains More Secure

GitHub, of course, is not the only CI/CD platform that has security issues. In the wake of a series of high-profile cyberattacks on software supply chains, security researchers more than ever are focused on uncovering vulnerabilities in DevOps tools, platforms and workflows. As more organizations embrace secure-by-design principles to build more secure applications, awareness of the need to make software supply chains more secure has risen sharply in recent years. The challenge is that given the sheer number of tools, platforms, pipelines and workflows that span a software supply chain the effort required to achieve that goal is gargantuan.

Unfortunately, cybercriminals have become more adept at, for example, stealing credentials that provide them with nearly unfettered access to application development environments. Once cybercriminals gain access it then becomes possible to, for example, embed malware in code bases that might not be activated until months later.

No developer wants to wake up one morning to discover a cyberattack has been traced back to a mistake they made. The trouble is that it’s too easy for developers to make a simple mistake that can have catastrophic consequences. It’s up to the DevSecOps teams to ensure that the software supply chain itself is as secure as possible. Otherwise, all the time and effort spent teaching developers how to write more secure code will likely to have been to no avail.

July 16, 2024
Ensuring Application Security from Design to Operation with DevSecOps

Safe development is critical for any company that creates software, whether for its own use or for others. DevSecOps principles focus on automating information security processes and introducing security measures early in software development. DevSecOps is extremely important these days as, according to recent surveys, more than 99% of tech professionals report that, on average, applications in production contain more than four vulnerabilities.

A study conducted by the Ponemon Institute and Rezilion reveals that 78% of those surveyed take over three weeks to address high-risk vulnerabilities in their systems. Furthermore, 30% say managing these vulnerabilities effectively takes more than five weeks.

Application vulnerabilities have become a primary channel for attacks driven by economic and political motives. But where do these vulnerabilities originate from? Firstly, they often arise from development practices, such as using unsafe programming structures or third-party components, frequently open-source frameworks and libraries. Developers might also insert shortcuts to accelerate the development process. Secondly, time constraints can lead to cursory code reviews that focus more on functionality than on thorough, safety-inclusive quality analysis. Lastly, the widespread use of outdated (legacy) software, known for its vulnerabilities and often difficult or impossible to update, contributes to this issue.

Main Stages of Secure Software Development

Using DevSecOps helps ensure the right level of security throughout both the development phase and the entire lifespan of the software. This method also concentrates on identifying and managing risks. By implementing safe development processes, there is typically an 80% reduction in vulnerabilities. Let’s explore the most important stages of this process, illustrated through the security development lifecycle (SDL) approach, widely adopted by many large corporations globally.

• Training
Everyone involved in software development, including all employees, contractors and other relevant personnel, receive training in cybersecurity basics and undergo regular instruction in secure development practices.
• Requirements
The development of each software product starts with clearly defining its security and privacy requirements. These requirements are shaped by factors such as the type of data the product will process, known security threats, established best practices, regulatory and industry standards and lessons learned from past incidents. Since software development is an ongoing process, the security and privacy requirements evolve throughout the product’s lifecycle, adapting to changes in functionality and the ever-shifting threat landscape.
• Design
At this stage, threat models are developed to help identify and categorize threats based on existing and potential risks. This process begins by outlining the different components of a product and how they interact in different functional scenarios, such as authentication. Data flow diagrams visually represent the interactions of data flows, data types, protocols, etc. It is important to keep threat models up to date throughout the product’s lifecycle, adapting them as the software evolves.
• Implementation
Implementation starts with developers coding according to the plan established in earlier phases. It is good to equip developers with secure development tools to incorporate all privacy, security and functionality requirements into their software. Such tools may include secure development environments, compilers and integrated security checks.
• Verification
Before the code is released, it undergoes thorough checks and approvals. Manual reviews are done by individuals separate from the code developers, ensuring a vital separation of duties to prevent any single person from both writing and releasing code. The step also includes a series of automated checks within the commit pipeline, covering aspects such as static and dynamic code analysis, binary analysis, credential and secret scanning, encryption scanning, fuzz testing, configuration validation and open-source software compliance.
• Release
Before launching software into products, a thorough review is conducted to verify if the security features implemented align with the initial specifications set during the design phase. Additionally, a contingency plan is developed to address potential security system breaches. Rather than deploying builds to all users simultaneously, they are incrementally rolled out to progressively larger groups.
• Response
Following their release, all software and services undergo comprehensive logging and monitoring to pinpoint potential security issues.

Main DevSecOps Tools

Let’s explore the tools essential for DevSecOps, integrating security principles into every stage of the software development process.

• Static Application Security Testing (SAST)
Static analysis is performed in a “white box” setting, enabling the detection of vulnerabilities without the need to run the actual code. This approach is most effective in the early phases of development, as it scrutinizes the source code directly, offering the chance to integrate the analyzer into the development pipeline for incremental scanning. However, it has drawbacks, such as a high rate of false positives.

Implementing a static code analyzer aligns well with the shift left concept, which emphasizes introducing checks as early as possible in the product development lifecycle rather than toward the end. This early integration significantly impacts the cost of fixing detected defects. For example, while fixing vulnerabilities identified during the development phase might cost X dollars, addressing these issues at the project release stage could escalate to 10 X dollars, and fixing them once the system is fully operational could soar to 100 X dollars.

• Dynamic Application Security Testing (DAST)
Dynamic code analysis operates in a “black box” scenario, where the tool does not have access to the source code and conducts tests while the program is running. DAST can mimic external attacks using common methods to find vulnerabilities in the application. DAST tools are not limited by programming languages and typically result in fewer false positives. However, their drawbacks include the potential to overlook vulnerabilities and miss certain functionalities because DAST does not fully cover the analyzed code.

• Interactive Application Security Testing (IAST)
IAST combines elements of both SAST and DAST to offer a more integrated and interactive way of detecting vulnerabilities.

Both IAST and DAST analyze live applications to find vulnerabilities. DAST tests the application’s interfaces like an attacker (from an external viewpoint), identifying vulnerabilities through response analysis. However, IAST also operates from within, blending insights from the application’s internal code and data flows with observations of its dynamic behavior during execution. This unique position allows IAST to uncover a wider array of issues, merging the depth of code analysis (similar to SAST) with the practical examination of running applications (similar to DAST). Consequently, IAST achieves greater accuracy and fewer false positives, pinpointing vulnerabilities that emerge only through the application’s operational context.

• Software Composition Analysis (SCA)
SCA scrutinizes open-source components and libraries within a software project. SCA identifies known vulnerabilities, licensing issues and outdated dependencies by examining the codebase against comprehensive databases of known security threats and compliance data. By integrating SCA into the DevSecOps pipeline, teams ensure that proprietary and open-source code adheres to security standards and compliance requirements.

Other Tools and Technologies

The tools mentioned above constitute the minimum set required to ensure the release of secure apps. To maximize your security efforts, it is also good to use additional technologies and tools that can support and enhance the secure development process. Here are some of them:

• Infrastructure-as-Code (IaC) Scanning
With the rise of cloud computing and infrastructure-as-code, scanning these configurations for compliance and security issues becomes critical during development.

• Container Security Scanning
Analyzing container images for vulnerabilities and configuration issues.

• Secret Management
Ensuring that secrets, such as passwords, tokens and keys, are securely managed and accessed is vital to protect access to applications, databases and services during development.

• Access and Identity Management (IAM)
Though not exclusive to the development phase, setting up proper IAM controls ensures that only authorized individuals can access development environments and resources. It can be supplemented with privileged access management (PAM) solutions.

There are many more strategies for ensuring the release of safe apps. For example, using a web application firewall (WAF) helps protect web applications by filtering and monitoring traffic between the web application and the internet.

Network detection and response (NDR) tools can detect and respond to network threats, while virtual private networks (VPNs) create secure internet connections. It is impossible to list all the options in this brief article. Choosing the right security measures depends on your available resources, including budget, expertise and technical capabilities.

Tool Integration and Workflow Optimization

One of the main goals of DevSecOps is to make security a seamless part of the development process, ensuring that security measures do not hinder but enhance development efficiency. Here are some expert tips for achieving this:

• Culture and Training
DevSecOps is as much about cultural transformation as it is about tools and processes. Before diving into technical integrations, ensure your team’s mindset aligns with DevSecOps principles. Underestimating the cultural aspects, such as resistance to change, fear of increased workload or misunderstanding the value of security, can impede adoption. You can address these challenges by highlighting the benefits of DevSecOps, celebrating successes and promoting a culture of learning and continuous improvement.

Developers should be familiar with the nuances of the security tools in use and how to interpret their outputs. Regular training and resources should be provided, empowering developers with the knowledge to address security issues, thereby fostering a proactive security culture.

DevSecOps hinges on breaking down silos between development, operations and security teams. Encourage regular meetings, joint projects and shared goals to build cohesive teams focused on secure development practices.

• Tools Used
Choose security tools that align with your needs and integrate smoothly with existing development and operations infrastructure. Favor those offering robust APIs, CLI support and compatibility with your CI/CD pipeline, as these features are crucial for seamless integration.

While the array of available security tools is vast, avoid deploying them simultaneously. This approach can lead to an overwhelming number of alerts and many false positives, cluttering your workflow. Instead, start with a strategic selection of high-impact tools and adjust settings to minimize unnecessary noise.

Prioritize automation in your security strategy: automate the execution of security scans, such as SAST, DAST and IAST, within your CI/CD pipeline. This automation ensures consistent security checks at every code development and deployment stage, significantly reducing manual intervention and accelerating the development cycle.

Continuous DevSecOps Improvement

DevSecOps is a journey, not a destination. Regularly review the effectiveness of your tool integrations and workflows. Gather feedback from all stakeholders and define metrics to measure the effectiveness of your DevSecOps practices, such as the number of vulnerabilities identified and remediated, the time taken to fix critical issues and the frequency of zero-day attacks and other security incidents. Use these metrics to demonstrate the value of DevSecOps and be prepared to adjust tools, processes and training for improvement.

Conclusion

The statistics are alarming: most applications have vulnerabilities, and fixing them can take weeks or even months, clearly showing that traditional methods are inadequate. Facing the ever-changing threat landscape, implementing DevSecOps practices is essential, not just recommended. Adopting the right mix of tools, practices and a shift-left mindset can significantly lower vulnerability risks.

June 28, 2024
Datadog DevSecOps Report Shines Spotlight on Java Security Issues

Datadog today published a State of DevSecOps report that finds 90% of Java services running in a production environment are vulnerable to one or more critical or high severity vulnerabilities introduced by a third-party library, versus an average of 47% for alternative programming languages.

Based on an analysis of IT environments being monitored using the Datadog platform, the report also notes 63% of high and critical vulnerabilities in Java applications derive from indirect dependencies that are traced back to third-party libraries that have been indirectly packaged with an application.

The report also notes that Java applications are disproportionately affected by the Known Exploited Vulnerabilities (KEV) catalog of vulnerabilities compiled by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Java applications can be impacted by 55% of these vulnerabilities, compared to 7% for other programming languages.

Just under a quarter of Java services (23%) are vulnerable to remote code execution (RCE), impacting 42% of organizations, according to the report.

It’s not clear to what degree organizations might be willing to abandon Java to improve application security, but there are already millions of Java services running in enterprise IT environments that DevSecOps teams need to secure.

Andrew Krug, team lead for security evangelism at Datadog, said it’s not likely organizations will resolve application security issues overnight. Instead, they should be focusing on continuous improvement over time that relies more on automation to ensure best DevSecOps practices are implemented and maintained. The report notes that 38% of organizations running applications in Amazon Web Services (AWS) were still manually deploying applications using “ClickOps” processes versus relying on a continuous integration/continuous delivery (CI/CD) platform.

The biggest challenge with DevSecOps is that not every vulnerability is always present in every application. The Datadog report, for example, noted that while the average service is vulnerable to 19 vulnerabilities, only 5% of vulnerabilities are being actively exploited.

DevSecOps teams should also assume every vulnerability rating is accurate. Datadog applied the Exploit Prediction Scoring System (EPSS) to rank the criticality of vulnerabilities. After applying an adjusted score, 63% of organizations that had vulnerabilities with a critical CVE severity no longer have any critical vulnerabilities. Just under a third (30%) of organizations saw their number of critical vulnerabilities reduced by half or more.

The report also noted that the smaller a container image is, the fewer vulnerabilities it is likely to have. On average, container images smaller than 100 MB have 4.4 high or critical vulnerabilities, versus 42.2 for images between 250 and 500 MB, and almost 80 for larger images.

In general, DevSecOps teams need to carefully evaluate not just how serious a vulnerability is, but also whether the vulnerability can be reached and is running, whether there is a known exploit and whether the software containing the vulnerability is running in a production environment. That’s critical because in 2023 there were more than 4,000 high and 1,000 critical Common Vulnerabilities and Exposures (CVEs) identified, but not every one of them represents the same level of actual risk to a business.

The Datadog report also noted automated security scanners employed by cybercriminals are more of a nuisance than an actual threat. Out of tens of millions of malicious requests that we identified coming from such scanners, only 0.0065% successfully triggered a vulnerability. It’s more important to have a framework to prioritize better prioritize alerts by monitoring raw web server logs or perimeter web application firewall (WAF) alerts. Failing to triage those alerts ultimately leads to a higher level of fatigue that, when vulnerabilities are missed, leads to higher levels of security nihilism, resulting in IT teams being blamed for breaches that are not really their fault, noted Krug.

It’ll be a while before software supply chains become more secure, but the one thing that is certain is that determining which vulnerabilities require immediate attention is critical to ensure developers still have enough time to build and deploy additional applications.

April 17, 2024
Survey Sees Limited DevSecOps Progress Being Made as Vulnerabilities Mount

A survey of 2,037 IT and security professionals conducted by the Cloud Security Alliance (CSA) on behalf of Dazz, a provider of a platform for mapping cloud computing environments, finds well over a third of respondents (38%) estimated that 21-40% of their code contains vulnerabilities, while 19% estimated 41-60% of their code contains vulnerabilities. Another 13% estimated they have vulnerabilities in 61-80% of their code.

As a result, organizations on average have 55.5 security vulnerabilities each day in their remediation queue, with typically at least one being deemed critical, the survey finds. Overall, the average number of vulnerabilities that could be addressed is 1,025 per month, but organizations typically only address 270 within a month.

In general, there are four phases to a remediation with each phase, on average, requiring between three to six hours so it easy to see how some organizations with limited resources can reach a point where they never catch up. The report noted that more than half of the vulnerabilities that have been remediated reoccur within a month, often because the root cause was never adequately addressed.

Hillary Baron, senior technical director for research for CSA, said the high number of vulnerabilities that need to be regularly addressed suggested that progress in adopting DevSecOps best practices remains limited. While not every vulnerability is equally critical, it’s clear application development and cybersecurity teams are not yet proactively addressing application security issues, she noted.

In fact, the survey found that less than a third (30%) of respondents reported there is a good working relationship between the application development teams that typically provision cloud computing environments and the cybersecurity teams that usually are held accountable for maintaining cloud security. Just under half of respondents (49%) said their vulnerability remediation teams comprised four to six members. Most respondents (60%) found it somewhat difficult to identify code owners, with an additional 24% facing moderate difficulty and 5% that found it highly challenging.

Dazz CTO Tomer Schwartz said the more dynamic application development becomes, the bigger the DevSecOps challenge. Most organizations lacked the visibility required to proactively correlate their DevSecOps practices, he added. For example, more than three-quarters (77%) of respondents said they lacked full transparency into their cloud computing environments, and 6% had no visibility at all.

In total, the survey finds organizations typically employ a variety of scanning and detection tools to safeguard their cloud environments, with 32% using five to six tools while another 29% report using three to four tools.

More than three-quarters of respondents (76%) also noted that one in 10 of the alerts these tools generate is a false positive.

Just under 75% of respondents also noted security teams spend more than 20% of their time performing manual tasks when addressing vulnerabilities, even though 83% reported using at least some automation in their remediation process. A full 61% also noted their organization is using three to six different detection tools, with nearly half (45%) considering increasing their security budgets in 2024, so it’s likely that many will be adding additional tools. In total, 22% dedicated less than 20% of their budget to cloud security, compared to 31% that allocated 21-40% of their budget and 27% that invest 41-60% of their budget to securing cloud environments.

Unfortunately, less than a quarter (24%) said they feel very prepared for the cybersecurity threats their organization faces. Much of that uncertainty stems from knowing just how many vulnerabilities there really are in production environments and that they are being attacked with greater frequency each day.

March 4, 2024
Cycode Brings Generative AI to App Security Posture Management

Cycode today added generative artificial intelligence (AI) capabilities to its application security posture management (ASPM) platform to make it simpler for DevSecOps teams to identify the root cause of vulnerabilities in complex distributed computing environments.

At the same time, Cycode is adding plugins for VS Code and JetBrains integrated development environments, a command line interface and pull request scanners to make it easier to identify security issues as early as possible during the software development life cycle (SDLC). Cycode also revealed today it now has more than 75 connectors to various security tools commonly used within DevSecOps workflows.

Amir Kazemi, director of product marketing for Cycode, said the company is using OpenAI’s generative AI platform to provide a natural language interface for invoking the Risk Intelligence Graph that is at the core of the Cycode ASPM platform. As part of that effort, Cycode is now also making available an Executive Dashboard that, based on all the dependencies uncovered, provides summaries of risks that make it easier to discern what is occurring across an application environment.

The platform, as a result, can now provide automated risk scoring for vulnerabilities based on actual severity and potential impact to the business, said Kazemi. The overall goal is to make it simpler to secure software supply chains by facilitating the proactive collaboration between application developers, DevOps engineers and cybersecurity professionals, he added.

It’s not clear what impact generative AI is going to have on how DevSecOps workflows are constructed, but making it easier to identify the root cause of security issues in application environments made up of monolithic applications, microservices and event-driven frameworks is now essential. Application security has simply become too chaotic to effectively manage without help from AI, noted Kazemi. In its current state, application security is simply unmanageable, he added.

The challenge is that just because a zero-day vulnerability has been discovered, it doesn’t always follow that application development teams know where every instance of it exists within their application environment. It’s not uncommon for DevSecOps teams to discover outdated versions of components that have known vulnerabilities to be running months after a patch in an updated version of that component has been made available.

DevSecOps teams are, of course, always trying to strike a balance between the level of threat a vulnerability represents and the possibility that the patch that should be applied might break an application. However, given the risk to application environments, it’s becoming less risky to patch an application than it is to hope that cybercriminals don’t exploit a known vulnerability.

While much DevSecOps progress has been made in recent years, it’s clear there is still much work to be done. Hopefully, generative AI will make it simpler for application development teams to address issues more rapidly than ever. In the meantime, however, DevSecOps teams should assume cybercriminals are looking to exploit the same AI capabilities to discover vulnerabilities they can exploit faster than ever.

February 21, 2024
Veracode Report Shines Spotlight on Massive Application Security Debt

An analysis of more than a million applications published today by Veracode, a provider of a software supply chain security platform, found 42% of applications contained flaws that remained unfixed for longer than a year.

Based on 1,553,022 dynamic analysis scans and 11,429,365 static analysis scans, the report noted that those applications with that level of security debt were found in 71% of the organizations maintaining these applications. Nealy half of organizations (46%) have persistent, high-severity flaws that constitute ‘critical’ security debt. Approximately 63% of applications have flaws in first-party code, while 70% contain flaws in third-party code imported via third-party libraries.

Remediation rates also vary by flaw type. Fixing third-party flaws takes 50% longer, with half the known flaws fixed after 11 months, compared to seven months for first-party flaws.

Collectively, the scan run by Veracode produced 96 million raw static findings, four million raw dynamic findings and 12.2 million raw software composition analysis findings.

Chris Eng, chief research officer for Veracode, said it’s clear too many organizations are kicking application security flaws down the road only to find they don’t have the time to address them properly. Meanwhile, cybercriminal syndicates and nation-states are becoming more adept at exploiting these flaws with each passing day, he added.

In general, there is a lot more focus on software supply chain security in the wake of an executive order issued by the Biden administration that requires federal agencies to identify and remediate security flaws. However, the pace at which enterprise IT organizations are following the lead of the Federal government varies widely. Only a relatively small percentage of the vulnerabilities that exist in applications running in production environments are being exploited, so many enterprise IT teams have yet to prioritize the issue.

However, as more cybercriminals acquire the skills required to discover and exploit those vulnerabilities, it’s only a matter of time before a major application security crisis ensues, noted Eng.

Theoretically, at least, artificial intelligence (AI) should one day soon make it easier to discover and remediate vulnerabilities, but it’s just as likely cybercriminals will use the same capabilities to achieve their own nefarious ends. In fact, it’s largely a race against time before existing application flaws are exploited using AI-based tools and techniques. Application development teams that fix flaws the fastest reduce critical security debt by 75%, from 22% of applications to just over 5%, the Veracode report noted.

Naturally, it’s less costly and simpler to fix security flaws before applications are deployed in a production environment, so the more organizations embrace DevSecOps best practices on the front end, the lower the overall security debt becomes, noted Eng.

It’s not clear whether organizations might decide to replace or consolidate applications to reduce their security debt, but given the overall lack of cybersecurity expertise among application developers, the current level of security debt is likely to continue to rise. The challenge, of course, is that as the security debt rises, the number of developers available to address, unfortunately, remains comparatively constant.

February 14, 2024
Squaring the Circle: How to Make Public APIs Private
APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

Day 2 API Security Solutions and Snowflakes

This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

A Difficult Race to Win

Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

Why Not Avoid the Race?

So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

Zero-Trust API Networking Needs to be Built for APIs

To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

There are usually three reactions to the diagram above:
1. OK, tell me how it works. See below.
2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.
How Zero-Trust API Networking Works

Here are the four pillars of zero-trust API networking:
1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code:
3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.
The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:
- Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
- Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
- Extensibility. Software-only, cloud-native architectures. Preferably open source based.
- Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
- Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
- Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
- Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.
Zero-Trust API Networking

While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.
February 14, 2024
Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

Lineaje this week revealed it has partnered with Persistent Systems to provide a managed service for remediating open source vulnerabilities that leverages artificial intelligence (AI) technologies.

Persistent is extending an existing open source software maintenance service by incorporating a Lineaje platform that makes use of machine learning algorithms to analyze software bill of materials (SBOMs) to provide recommendations for fixing code and surface remediations such as updates that should be applied.

Lineage CEO Javed Hasan said Persistent Systems is augmenting that capability with a dedicated team of specialists that IT organizations can contract to maintain open source code along with previous investments the managed service provider has made in large language models (LLMs) that add generative AI capabilities.

Options for the services range from simply identifying issues that an internal IT team should address to a white glove offering through which Persistent Systems ensures all open source components are continuously updated.

In the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, more attention is being focused on the inherent cybersecurity risks associated with employing open source software to build applications. Many open source projects are led by a handful of maintainers that often lack the time and skills required to ensure the components they employ have not, for example, been compromised by malware that might find its way into downstream applications.

Those maintainers are not being paid, so cybersecurity patches to open source software might not be readily made available, and even when they are, many organizations lack the skills and resources required to apply them in a timely manner. The majority of known vulnerabilities within application environments are still unpatched. Many IT teams are also reluctant to upgrade components for fear of breaking applications that have dependencies that are often difficult to track.

It’s not known how much of the open source software that many developers routinely incorporate into their applications might contain vulnerabilities that could be exploited, but the level of technical debt that has accrued over the last several decades is considerable. While only a small percentage of those vulnerabilities have been exploited, cybercriminals are becoming more adept at discovering them.

Hopefully, more contributions to open source projects will improve the overall state of application security, but in the meantime, it’s clear organizations will need to rely more on AI to drive DevSecOps workflows as ever-increasing amount of open source software continues to be relied on to build applications, said Hasan.

The challenge, of course, is identifying which vulnerabilities, if exploited, will have the biggest impact on the organization. After all, at this point, it’s not possible to defend every application so the focus needs to be on prioritizing remediation efforts based on their actual severity rather than a general rating.

In the meantime, DevSecOps teams would be well-advised to have incident response plans in place for remediating breaches involving both known and zero-day vulnerabilities that, in addition to being all but inevitable, can now be exploited within minutes of being discovered.

November 22, 2023