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.

  • DevOps’ Role in Fixing Software Vulnerabilities

    DevOps’ Role in Fixing Software Vulnerabilities

    From the beginning, application development has required that software developers deal with bugs, vulnerabilities and other issues. But problems encountered under the DevOps model tend to be more manageable since the updates and fixes required are usually smaller. The reason for this is that the process of maintaining and improving DevOps-related software never stops. In other words, problems that do need to be corrected are typically tackled faster under the DevOps model.

    In looking at the DevOps cultural shift that has fast-tracked the software development process while making security part of that process, it’s critical to consider how the DevOps process impacts software development, the issues around hackers taking advantage of vulnerabilities in code and why companies need to protect their infrastructure that incorporates speed and security.

    How DevOps Practices Impact Software Development

    DevOps practices impact every level of the software development process. In the past, software developers would churn out new app versions, sometimes every few years and sometimes every couple of months.

    This afforded developers sufficient time to go over their code with a proverbial fine-tooth comb. It also allowed them to devote more time to quality assurance efforts, which helped to minimize vulnerabilities that hackers could use to their own advantage.

    But the rise of DevOps has drastically revolutionized the way software is developed and delivered to customers. Instead of releasing new versions of apps perhaps yearly, software developers operating under the DevOps model can release updates and fixes quickly and on an ongoing basis.

    Facilitating the software development process over the course of the DevOps life cycle are tools such as Jenkins or Docker that allow the automation of many procedures and applicable processes.

    Quite simply, DevOps practices positively impact software development. The benefits can be broken down into three categories, namely technical, cultural and business, and as can be seen below:

    1. Technical Benefits: Ongoing software development, less complexity to take on and faster resolution of problems or issues.
    2. Cultural Benefits: Teams more fulfilled and productive, greater worker engagement and more professional development options.
    3. Business Benefits: Speedier delivery of features, more durable operating environments and better collaboration.

    It goes without saying that DevOps has a major and even revolutionary impact on the process that software development teams use to create applications as well as to fix vulnerabilities. It proves that doing things faster doesn’t have to mean proceeding in a haphazard manner.

    Issues Around Hackers Exploiting Code Loopholes

    Implementing the right processes and procedures can cut down on exploitable vulnerabilities. But software developers understand that hackers wake up each morning scheming up new ways to exploit code and infrastructure, which is why the struggle never stops. One of the issues customers are justifiably concerned about is privacy.

    The answer is to take DevOps to the next level. In other words, software developers need to adopt the DevSecOps model, which refers to implementing open source security procedures in the beginning stages of the software development life cycle. Open source security measures are essential for DevOps security teams because of the fact that they are lower cost, more innovative and allow teams to make the most of their continuous delivery processes. This includes, but is not limited to, code analysis, vulnerabilities assessments and compliance monitoring.

    When software teams purposefully and intentionally implement security practices within an Agile framework, they will be able to safeguard the integrity of their codebase. This can be accomplished with continuous evaluation, testing and updating.

    Why Businesses Need to Maintain Fast and Secure Infrastructures

    More companies are investing in protecting their infrastructure than they ever have before, as infrastructure protection spending this year could reach $17.5 billion worldwide, up from $12.6 billion in 2017. So while there is crystal clear evidence that more companies recognize the need to protect their infrastructure from nefarious actors, they are also, in fact, doing something about it.

    The consequences of failing to maintain a fast and secure infrastructure can be disastrous. Consider the following statistics that show some of the problems that can materialize: On average, it takes 206 days just to identify a data breach, and over 30% of companies encountered cyberattacks on operational technology infrastructure last year alone.

    So what can software development teams do to help organizations maintain secure infrastructures at a time where hackers are tirelessly persistent? While customers expect software to be delivered post-haste, they also expect it to be secure.

    Software developers need to commit to DevOps and DevSecOps to ensure that the software they develop and deliver to customers is free of exploitable vulnerabilities that could jeopardize their infrastructure, scare off their clients and even potentially wreck their operations altogether.

    Customers also have a role to play to keep their infrastructure safe. They should, for instance, have policies in place to govern how their workers use the software, roll out updates and fixes as soon as they are available, and use the right tools to protect their infrastructures.

    Conclusion

    By leveraging the DevOps model to make security part of the corporate culture and by training team members so that everyone adopts coding habits that are rooted in security, and by automating security in the development process, software development teams can deliver safe products quickly.

    At a time when customers expect deliverables fast, software development teams need DevOps so they can go from the development stage to the delivery stage without needless delay. The DevSecOps model is one in which security is purposefully implemented at each stage of the software development process, not simply a value-added component.

  • 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.

  • Synopsys Advances DevSecOps via IDE Plugin

    Synopsys Advances DevSecOps via IDE Plugin

    Synopsys has extended the static application security testing (SAST) and software composition analysis (SCA) of the Code Sight plugin it makes available for integrated development environments (IDEs).

    The latest iteration of Code Sight adds the ability to analyze declared and transitive open source dependencies to identify components with known security issues alongside SAST findings without having to exit their IDE.

    Delivered vis the company’s Polaris Software Integrity Platform, the update enables developers to also review known vulnerabilities of flagged components to verify the risk and determine remediation options using vulnerability information from Black Duck Security Advisories (BDSAs). That information is based on data provided by both Synopsys and public CVE records gathered in the National Vulnerability Database (NVD).

    Patrick Carey, director of product marketing for the Software Integrity Group at Synopsys, said the Code Sight plugin enables developers to easily identify and select the best fix for vulnerabilities by providing detailed remediation guidance that directs them to more secure component versions.

    Code Sight also helps developers optimize component selection by including, for example, information regarding open source license risks and potential security and license compliance violations of an organization’s predefined set of open source policies.

    In general, Carey said Code Sight is designed to make it easier for developers to address a broad range of cybersecurity issues while an application is being developed instead of after it’s deployed. The goal is to make it easier for developers to discover and address cybersecurity issues on their own as part of the overall shift toward adoption of best DevSecOps practices, he said.

    The challenge, of course, is most developers have not been trained to identify potential cybersecurity issues in their code. Code Sight fills that gap by surfacing vulnerabilities as developers write code, said Carey. Synopsys plans to continue building on that capability by adding more analytics capabilities to the Code Sight plugin over time, he added. For example, Synopsys earlier this year acquired Tinfoil Security, a provider of dynamic application security testing (DAST) and application programming interface (API) security testing tools that will be employed to surface additional analytics in Code Sight.

    Eventually, the goal is to make identifying cybersecurity issues a natural extension of the quality assurance process within any application development and deployment life cycle, Carey said.

    It’s hard to say with certainty to what degree DevSecOps will be driven by a set of well-defined best practices versus simple evolution of how applications are developed. There’s no doubt cybersecurity professionals have a vested interest in making sure fewer vulnerabilities make it into production application environments. As such, communication between developers and cybersecurity professionals clearly needs to improve. However, the biggest DevSecOps strides any organization might make may simply come down to making the right tools available in the most frictionless way possible to developers.

    In the meantime, there’s no doubt application security has become a major area of focus in the age of digital business transformation. The challenge now is limiting the number of vulnerabilities that might be exploited as more code than ever is developed and deployed at increasingly faster rates.

    — Mike Vizard