Tag: code vulnerabilities

  • ActiveState Makes All Tiers of Curated Artifact Repository Service Free

    ActiveState Makes All Tiers of Curated Artifact Repository Service Free

    ActiveState today announced it is making all tiers of its ActiveState Artifact Repository service available for free for a limited time. The move aims to enable organizations to better secure open source software components incorporated within applications.

    Loreli Cadapan, vice president of product for ActiveState, said the ActiveState Artifact Repository exposes a set of curated instances of open source software for creating binaries that are validated to be secure. That capability reduces the likelihood vulnerabilities will be inadvertently introduced into application environments by developers that have downloaded open source modules from repositories that may contain compromised code, she added.

    In addition, the ActiveState Artifact Repository also makes it possible to automatically generate software bills of materials (SBOMs) that identify which software components were used to build an application after all the code used to construct an application is stored in the repository, Cadapan noted.

    ActiveState’s repository is delivered as a cloud service to organizations that would otherwise have to build their own. Cadapan noted that the goal is to make managing and securing software supply chains simpler when more attacks are being launched against them.

    Most organizations have limited visibility into how they are consuming open source software. It’s become apparent many organizations have no idea what software components have been incorporated across their software supply chain. As a result, when a vulnerability is discovered, there’s no easy way for them to know whether they are impacted.

    However, awareness of this issue has risen, thanks to an executive order issued by the Biden administration which requires federal agencies to have an SBOM for every application they employ by next summer. The executive order was issued in the wake of a zero-day vulnerability in the Log4j tool discovered late last year that is widely used to create logs within Java applications. Many organizations are still looking for all the vulnerable instances of Log4j in their application environments. SBOMs must provide a list of the “ingredients” used to create an application to make it easier to find any component that might one day be similarly affected by a zero-day vulnerability.

    Organizations that want to implement a similar SBOM policy will spend massive amounts of time cataloging software on an ongoing basis. Every time an application is updated, there will be a need to once again verify what components are being employed within the context of larger DevSecOps workflows.

    SBOMs will undoubtedly play a critical role in improving overall application security. However, having an SBOM is not the same thing as operationalizing it. Organizations are ultimately hoping to be able to use an SBOM to decide whether to green-light the deployment of an application, so DevOps teams should expect to be required to not only provide an SBOM but also continuously update it. The challenge, of course, will be determining how many internal resources to devote to that effort versus relying on external platforms to manage that process.

  • GraphQL Vulnerability Analysis: The Top Threats

    GraphQL Vulnerability Analysis: The Top Threats

    Publicly available vulnerability data can be a goldmine for insights into how DevOps and DevSecOps teams can prioritize threats and improve security across the pipeline. With this in mind, Inigo recently performed a deep-dive analysis of known vulnerabilities affecting GraphQL components—including GraphQL clients such as Relay and GraphQL servers such as Apollo, Graphene, Ariadne, GitLab Enterprise, Magento and others. Our main data sources for this investigation were the MITRE CVE database and the HackerOne Hacktivity portal.

    Analysis and Findings From the MITRE CVE Database

    First, a few caveats about the MITRE CVE database. While it’s considered the source of truth for CVEs and the best data source available for understanding these vulnerabilities, it has its limits. Not every vulnerability gets reported, and not every reported vulnerability gets an assigned CVE identifier. Vulnerabilities generally receive a CVE identifier when an impacted software vendor or researcher recognizes a vulnerability and files a CVE request with MITRE. Large software vendors including GitLab, GitHub, Adobe and many more also serve as CVE Numbering Authority (CNA) partners, authorizing them to issue CVE identifiers themselves (often only for the scope of their own software). All this is to say that the MITRE CVE database is a strong data source for our analysis, but it shouldn’t be considered comprehensive.

    Inigo started its investigation by searching the MITRA CVE database for the term “GraphQL,” revealing 45 CVE records (at the time of the research) relevant to GraphQL clients, servers, and other components. Interestingly, the first tracked GraphQL vulnerability was CVE-2019-1000011 from 2019: Most likely not the first vulnerability ever discovered in GraphQL software, but the oldest available in this database.

    Researchers were curious to know which classes of GraphQL vulnerabilities were most common, and which GraphQL software has the most known CVEs. The following chart displays the results of the analysis answering the first question.

    Authorization bypass vulnerabilities are far and away the most common vulnerability class, and a majority representing 54.8% of all GraphQL vulnerabilities. At 16.7%, denial-of-service (DoS) vulnerabilities stand out as the second most common vulnerability class, followed by information disclosure (9.5%), code execution (7.1%), cross-site request forgery (CSRF) (7.1%) and injection (4.8%).

    Analysis into which GraphQL software has the most CVEs revealed the following:

    To be clear, these findings don’t necessarily speak to how hardened or how safe a particular GraphQL component is. Popular GraphQL servers simply draw more attention and have more eyeballs searching for vulnerabilities, whether they belong to attackers or security personnel. While this fact skews these results, viewing this data at a glance remains interesting.

    Analysis and Findings From the HackerOne Vulnerability Database

    The HackerOne Hacktivity portal offers a robust database resource that collects information on vulnerabilities as reported by researchers. The analysis looked at public reports of GraphQL vulnerabilities, finding 74 results since 2018.

    As the graph shows, identified GraphQL vulnerabilities fell mostly into the authorization class (87%), with DoS (7%) a far second and race condition and session management vulnerabilities each coming in at 2.8%.

    Bug bounties offer an interesting and likely influential factor here. Over the 2018-2022 timeframe, bug bounties granted for these vulnerabilities ranged from $250 to more than $20,000. At the same time, authorization vulnerabilities carry a high risk to sensitive data such as personally identifiable information (PII). This drives organizations to place premium bounties on these authorization flaws and motivates security researchers to focus on earning those prizes. Therefore, white-hat hackers will naturally test for authorization flaws first, perhaps leading to their overrepresentation in the data. It’s also important to note that bug bounty programs tend to prohibit testing for DoS vulnerabilities for obvious reasons, possibly reducing their representation here.

    Open-Eyed GraphQL Security

    For developers, DevOps and security teams tasked with safeguarding GraphQL deployments, the first step is knowing what you’re up against. The findings above should serve as an eye-opener that helps teams to prioritize threats, whether they be authorization, DoS and other classes of GraphQL vulnerabilities. As more and more organizations rush into GraphQL (increasingly migrating from REST APIs), security cannot be put on the back burner. There’s too much at stake, and ensuring the security of GraphQL deployments isn’t nearly as difficult or time-consuming as many teams currently think.

  • The Two Types of Code Vulnerabilities

    The Two Types of Code Vulnerabilities

    Spell checkers, grammar checkers and predictive keyboards all help reduce errors in written communication, but in a creative medium where writers need to innovate new expressions, nothing can eliminate all errors. The same is true in the code we write.

    Of course, your code is probably perfect but, on average, all code has bugs. Some of those bugs are benign. Some will cause unexpected early termination. A few will cause runaway resource consumption. And some bugs lead to security vulnerabilities that let users do things that are unexpected and sometimes undesirable.

    Those security bugs are behavioral vulnerabilities because they depend on how the code behaves when executed. Another type is an intelligence vulnerability, something that’s part of the correct behavior of the code, but which gives away details about how to exploit a system. These are the two main types of code vulnerabilities; both come with risks.

    Behavioral Vulnerabilities at Runtime

    Tl;dr: How the code works and how attackers can leverage what it does to their advantage.

    This covers a broad range of problems, but all of them are a result of the behavior of the code leading to undesirable outcomes in specific circumstances. Most of these are unintentional. An unescaped user input sent to a database can lead to a SQL injection vulnerability or an unsanitized string sent to a browser could create a cross-site scripting (XSS) vulnerability. Some behaviors are intended, but have unexpected consequences; the Log4j string substitution behavior that allowed it to output environment variables or read data from external resources was intentional, but the malicious usage we now call Log4Shell was not. In another recent example, a combination of behaviors could be exploited to gain root privileges on Linux desktop computers.

    Intelligence Vulnerabilities in the Content

    Tl;dr: What the content of the code tells an attacker about the system and how to access it. 

    In the 1950s, the phone company—there was pretty much just one at the time—began implementing completely automated dialing that didn’t require a human operator at the switching station to connect the call. The details were first published in a technical journal in November 1954 (see pages 1209 and 1309 here), and the information gleaned from that led to the creation of “blue boxes” that used insider knowledge to allow outsiders to control telephone equipment and make free long-distance calls.

    That’s hardly the first example of insider knowledge being leveraged for outside advantage, but its role at the heart of computer hacking and the origins of the PC (the ‘hack’ inspired Wozniak and Jobs) is so legendary that it demands recognition here.

    The phone system’s intelligence vulnerabilities were published in the company’s technical manuals—manuals that many thought were only for internal use, and nobody realized were available to untrusted readers. Today, though, intelligence vulnerabilities are in our code.

    Secrets abound in code, along with the details about which systems those secrets connect to. These secrets were once difficult to manage and putting them in code was the only practical choice. Now we have tools like Hashicorp Vault, as one example, and secure keystores in almost every cloud, but the legacy and security debt of all those secrets in legacy code are a goldmine for attackers like Lapsus$ and others who specifically target code.

    Security Is a Process, not a Product

    There’s a lot hidden under the surface in the two categories outlined here. Each of us can name many types of behavioral vulnerabilities—many more than the different types of intelligence vulnerabilities—but the two classes of vulnerabilities represent relatively equal risk. Recent events have demonstrated how an attacker with inside knowledge gleaned from code—and with passwords and keys taken from it—can move quickly despite firewalls and other access controls.

    Identifying secrets and other intelligence risks in code is relatively easy, but few teams do it because detection is the easy part. Integrating detection in developer workflows so they can take action in-context while working on and reviewing code is the most effective way to eliminate creating new security debt. And tools that give developers the information they need to understand the overall picture of intelligence risks in their code, the areas of highest risk—and that point them to actionable issues they can fix immediately to improve their code health—are necessary to help teams mitigate historical risks, ideally by rotating any secrets found.

    Tools exist that can automate that process and help teams to eliminate more than half the risk in their code—but the first step is recognizing where that half resides.

  • Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    A recent report asks the tough questions about DevSecOps adoption, and the results are surprising

    In a world of increasing development velocity, companies are placing more responsibility on developers to enact quick deployments. Naturally, security is “shifting left” as well.

    Theoretically, DevSecOps sounds great, but it opens up many questions. Who exactly is responsible for security knowledge? Are cybersecurity training measures effective? Which tools excel at decreasing risk while maintaining release fluidity? Are AppSec tools aiding or adding unneeded friction?

    A report conducted by Enterprise Strategy Group (ESG) sought to answer these pressing questions and expose trends around application development security. The study surveyed 378 IT, cybersecurity and application development professionals at organizations in North America.

    I recently met with Chris Eng, chief research officer at Veracode, and Dave Gruber, senior cybersecurity analyst at ESG, to dig deeper into the report’s findings.

    Security vs. Development

    There is still friction when attempting DevSecOps in practice. Eng recognizes a disconnect between security and development teams.

    “Most security teams lack an understanding of modern application development practices,” said Eng. Security may not realize how regularly code is pushed or understand the intricacies of tooling within a CI/CD pipeline. On the flip side, developers may not be well-versed in common container exploits and vulnerabilities.

    Organizations are pretty split when it comes to application security testing ownership. Thirty-one percent of organizations dedicate security analysts to manage application security. The development manager and security team jointly own responsibility at 29% of companies. Developer managers follow at 26%, and individual developers at 13%.

    To Eng, these figures reflect an evolution from traditional security testing to the way things are changing with faster development cycles. “Go back 10-plus years, and we had a centralized, dedicated security team responsible for managing AppSec,” described Eng.

    In modern times, security is shared or even furthered where developers themselves run tools by hand or automate security within CI/CD processes. Large companies, Eng noted, now often utilize a mix of those practices.

    Paradox: Secure Yet Vulnerable

    Seemingly, the most eye-opening part of the report was a paradox. The report found that most teams give their application security a high rating (36% gave their application security programs a 9 or 10, with a 7.92 mean). Yet, the majority say they regularly push vulnerable code (48% of respondents knowingly push vulnerable code regularly).

    Though it’s counterintuitive, organizations may knowingly push out vulnerable code for many reasons. “You’ve promised a release, customers are waiting, ” said Eng. “Revenue is waiting. What are the implications of pushing that release?” Teams may not have time to fix vulnerable code, or it may simply not be worth it.

    Publishing vulnerable code may also be a symptom of placing testing too late in the release process. “That’s why there is this trend to shift left,” added Gruber.

    Gauging DevSecOps Success

    The above findings underscore a reality of IT security: To keep pace, software providers must accept a level of risk. In fact, business success may depend on it.

    “The effectiveness of the programs isn’t necessarily measured with how many times you’ve shipped your code with no vulnerabilities,” said Gruber. “Success is that we understand the risk, we have mitigated the risk at the level we believe is right for the organization, and have the right level of control over the process.”

    Companies must weigh the cost of improper DevSecOps and mitigate imminent risk to maintain release agility.

    Application Security Tools: Finding Balance

    At modern companies with quick-release cadences, “CI integrative security tools are way more prevalent and baked into the process,” noted Eng. Yet, 26% of respondents indicate security tooling friction and ineffective tooling usage.

    Whereas InfoSec teams are usually the ones dictating policies, developers have much influence in the tooling selection. Thus, tools must appeal to the developer experience, fitting into their established workflows.

    “We have to build a habit around it,” said Eng. Frictionless tools that continually scan within an IDE, for example, can enable developers to fix an issue on the spot and foster future behaviors.

    At the same time, you must set standards and avoid governance issues. This requires control and observability. “The balance here is that you want developers to be able to integrate something tightly into their toolchain,” said Eng. “But InfoSec needs a bird’s eye view on the organization.”

    Developers Lack Knowledge to Mitigate Issues

    Though security tools may reveal vulnerabilities, they don’t always correlate with remediation. The ESG report found 29% of developers lack the knowledge to mitigate issues identified by security tools.

    There is a clear gap in the market when it comes to developer education around security. This could stem from computer science schooling, in which cybersecurity is rarely taught alongside programming languages.

    On the job, hands-on developer security training is also spotty. Thirty-five percent say that less than half of their development teams are participating in formal training. Only 15% of organizations have developers actively involved in security training.

    Just giving developers a laundry list of vulnerabilities doesn’t help mitigation. For Eng, what organizations require is habitual, recurring training with hands-on tools. “Try to simulate or provide a real-world environment for learning, identifying and patching these issues,” recommended Eng. Integrating tooling within the daily developer workflow can help with knowledge retention, because “if you don’t use it, you lose it.”

    Other best practices will only arise with a security habit. For example, most development environments ship with open defaults. “You need security training and tools to understand to restrict that appropriately,” noted Eng.

    That said, a wide variety of security tooling is already advancing this process. For example, 56% of organizations use API security vulnerability (ASV) scanning to identify and mitigate risk associated with API usage, helping secure applications as developers code dependencies.

    Final DevSecOps Thoughts

    The ESG study found 43% of participants believe DevOps integration is most important to improving AppSec programs. Yet, siloed roles and a lack of security education mean DevSecOps must still mature quite a bit to meet the security-shift-left vision.

    Other eye-opening findings included:

    • More than half of respondents (54%) use automated controls to identify and quarantine vulnerable images in their image repository.
    • The proliferation of AppSec tools on the market is a significant problem for 30% of companies.
    • AppSec spending is increasing, yet only 30% will protect more than three-quarters of their codebase 12 months from now.

    For more findings, check out the ESG Survey Report: Modern Application Development Security.