devopsy.kinsta.cloud

Tag: software composition analysis

  • The Scariest Things About SCA

    The Scariest Things About SCA

    It is a time of ghouls, mischievous spirits and David S. Pumpkins. In the spirit of Halloween, here are the top five scariest limitations of software composition analysis (SCA) tools that are enough to send shivers down your spine. Read on … if you dare!

    1. SCA Scans Only Your Application Code

    SCA’s scope is frightfully narrow. When scanning for vulnerable dependencies, SCA only examines your source code even though vulnerable dependencies used to build your software can exist throughout your entire development pipeline. Vulnerable dependencies can be found in dev tools like Jenkins, dev tool plugins like Jenkins Plugins, build modules like GitHub Actions, build module dependencies like GitHub Actions libraries, and infrastructure-as-code (IaC) dependencies. If you’re only scanning application code, you should be shaking in your boots because it is not enough to protect against modern software supply chain attacks like SolarWinds or Codecov.

    The good news is that next-gen SCA, pipeline composition analysis (PCA), scans your application code and your entire pipeline for vulnerable dependencies. PCA improves upon the foundation of SCA by including a deep understanding of the tools, configurations, processes, activities, components and dependencies used at every stage of the delivery pipeline. When new dependencies like Text4Shell are disclosed, you can be sure every instance of the vulnerability is found and remediated. This way you know you don’t have any proverbial skeletons lurking in your software’s closet.

    2. SCA Can’t Tell You Where Vulnerabilities Are Deployed

    Vulnerability remediation can be ghoulish. When new high-severity exploits are disclosed, you need to remediate every instance of the vulnerability from all production environments where it could be exploited–and you need to do it fast. Identifying a vulnerability like Log4j in your code base is a start, but you’re not truly secure until you have removed every instance of the vulnerability in production systems where they pose a real risk to your organization. Though traditional SCA can tell you where a vulnerability is in your application code, it has no visibility once that code has been deployed.

    PCA gives you visibility into your entire development pipeline, including production environments. This enables you to easily trace the path of a vulnerability from code to deployment locations, such as identifying which Kubernetes clusters contain a specific vulnerability. This enables organizations to be more agile in their response to newly disclosed threats and ensures that every instance of a vulnerability has been remediated.

    3. SCA Doesn’t Correlate Risk Across AppSec Engines

    Some traditional SCA solutions may be able to collect data from various scanning engines, but they are terrible at making meaningful connections between various data points. Because of this, “traditional” SCA is unable to provide the context required to deliver an accurate and nuanced assessment of the impact of one event and how risk might be compounded by other related events. SCA without context generates too many false positives—this results in your team wasting time chasing ghosts.

    PCA correlates risks and threats across all phases of the SDLC as well as from all AppSec scanning tools. By connecting the dots from numerous data sources, PCA helps your security and DevSecOps teams understand holistically how risks relate to each other so they can best tackle the most important security initiatives first.

    4. SCA Ignores Pipeline Security and Governance

    Modern development pipelines are complex and deeply interconnected–almost as if they are stitched and bolted together like Frankenstein‘s creation. Though managing security policies across the entire SDLC is an arduous and painful task, it is essential if you want to prevent software supply chain attacks. Unfortunately, traditional SCA solutions don’t even come close to helping you manage pipeline security and governance policies like enforcing least privilege or hardening authentication.

    Pipeline composition analysis identifies pipeline tooling misconfigurations and helps you implement best practices for security controls across your entire pipeline. Even better, to prevent your tooling from being bypassed, PCA alerts you when pipeline security controls like SCA scanning are removed or disabled.

    5. SCA Provides No Visibility into Your SDLC

    Traditional SCA solutions focus only on application code. They provide no visibility across your SDLC. They were not designed to scan development and deployment environments, so they cannot secure the later parts of your SDLC. SolarWinds was infiltrated via its TeamCity build server, which traditional SCA tools did not scan. So how can you protect your software supply chain if you can’t see it? Don’t be haunted by SCA tools’ inability to scan the entire SDLC.

    Vulnerable dependencies that impact your application can be found across the SDLC. You need to understand all development and deployment tooling–activity, settings, configuration, users and more–to protect your application. Pipeline composition analysis was designed from the ground up to understand your SDLC and bring context to your SCA findings to improve accuracy. It can give you complete visibility into the big picture to cut down on all the noise that traditional solutions generate.

    Pipeline Composition Analysis: Put Your Nightmares to Rest

    While it’s fun to be scared at Halloween, the last thing you want is to be terrified by your AppSec program. When the limitations of traditional SCA solutions threaten to keep you up at night, just remember that AppSec innovation requires the ability to do pipeline composition analysis across the entire SDLC, hence the shift from SCA to PCA. PCA plugs all the holes mentioned here, which hopefully can put even the worst nightmares to rest.

  • SCA, SBOMs and Floodgates

    SCA, SBOMs and Floodgates

    Two criteria are used to determine pervasiveness of a new idea. Availability of an easy-to-understand solution and customer need. Given both of these items, what might be a market-differentiating feature available in a single IT/DevOps market becomes a wave of options in multiple markets that an organization can (and should) choose from.

    What started this off? Well, I’ve been working in areas that involve expansive use of open source. This is pretty much to say, “I’ve been working in IT,” at this point, but that’s a different blog. The thing is, today, working with open source implies a complex software infrastructure that, traditionally, no one actually had a handle on. What is directly included in that project? What is indirectly included in that project?

    But then we had some pretty stellar security issues related to commonly-used open source. And we had commonly-used programming language modules pulled out from under hundreds of thousands of applications. Then we started paying attention. Or, more accurately, then we finally set out to fix a problem we’d been ignoring.

    This market is a bit confused by different use cases and the fact that there are two toolsets to achieve what IT sees as one job. So let’s talk about the complexities, just for clarity. First off, a software bill of materials (SBOM) is the list of what is included in a software project. The complexities here are twofold. From a programming perspective—meaning tools designed to be used by programmers during development—“included” means libraries, modules, etc. that the application calls on to do what the organization needs. These are “included” in the build process. From a systems perspective, “included” means everything installed on the image when it goes to production. These are similar but very different lists. The developer list is a subset of the production list because all of the items in the development list are included in production, but the production list will have other software that is used to support the developed application. Think of the application having all of its libraries and modules, but assuming SSL termination will be there. Because it will. In the image. That’s the difference. Many products have had an internalized version of SBOM for years now—developer security tools and release scanning tools pretty much require a list of everything they need to scan. But few made these lists public, and many tools did not have them.

    Software composition analysis (SCA) takes the SBOM and adds value. While a list of everything included is useful, a subset that lists everything that’s actually used is more to the point, for example. So is a list of flaws found in included libraries/packages and suggestions on how to address them. This can be done from either the source or production SBoM side, depending upon implementation.

    Once the value of both tools was made clear—and implementations existed that showed both how to implement them and what the benefits were—the floodgates opened. Now there are few DevOps or security tools that do not offer one or both of these features. That gives us an embarrassment of riches. Which tool(s) do we use for compliance and security review? As we do with data, I’m going to suggest that a single product is chosen as the “source of truth” and run with. At this time, I do not have suggestions on which ones are better for this purpose, just a suggestion that if you use different ones for different purposes you are likely to get different results, and that isn’t going to help simplify things at all. So, look at the ones you already have access to—they’re in enough products that you likely have more than one available in your existing infrastructure—and make it your standard.

    Then, use that standard to help monitor use of open source. Monitoring can help with open source licensing, with application and infrastructure security, with image simplification and with compliance. So strip unused packages out of images and clean libraries that are no longer called out of your build process. Respond to issues faster, and keep that application infrastructure you’ve been nursing along humming. And keep kicking it; your users should appreciate it, even if they do not.

  • DevSecOps Tools: Hot Air Ahead

    DevSecOps Tools: Hot Air Ahead

    I, like most of you, don’t like hardcore marketing that hinges its statements on “Well, that’s technically true…” I also am not a fan of talking heads that spew predictions about the future. Sure, they’re right sometimes; that’s because we have so many people pontificating that random distribution means some will be correct. I am bringing all this up to warn you that I (basically a high-tech talking head) am about to talk about tools, the future of tools markets (one in particular) and what I think should/will happen.

    Sometimes, talking about the future of a given tech is done to make a name for yourself. I don’t play that game. My goal is simply to say, ‘This is what I would like to see, and why I would like to see it.’

    Enough spewing—let’s talk about DevSecOps tools. I jotted down this topic a while back when I touched briefly on it, and my ideas firmed up while working on a recent project.

    Let’s start easy. If you are not using what we currently call DevSecOps tools in your DevOps toolchain, go get them set up. Go ahead, we’ll wait. It’s that much of a no-brainer that we’ll sit here while you choose, purchase and install your choice. Seriously. “Here is a tool that will make development more secure and make developers more productive.” Go install it now. Choose what functions you want to use and work them into your toolchain.

    But don’t get too married to your vendor. Because for the very same reasons I just told you to go install them, I will say I don’t think they should be a standalone market. Here is a toolset that plugs into the IDE on one end, and runs stand-alone, integrated with CI/CD on the other. It is DevOps in many ways. And while code scanning is inarguably a security function, the spirit of DevOps overall is “Who cares?” Using these tools shifts quite a bit of security functionality left and also warns about bad coding practices. Note I did not specifically say insecure coding practices, though those are covered. I said bad coding practices. The largest of these vendors will let you know things like, “Hey, you sent that variable to this function and then never used it. Are you sure?” or “This loop looks like it never exits. Are you sure?”

    It should be, and I predict will be, part of the DevOps process. In my dream world, the functionality would get split and some would end up in IDEs, while the rest would end up in testing tools or CI tools. But that’s not normally how markets get split up when there are established vendors. Even though you can feel the difference in the functionality (a bunch of them plug right into the IDE; the rest don’t), it won’t get split up because existing markets generally merge through acquisition. So we’ll have to see how things fall out, but I’m betting on CI/CD vendors or system-wide security vendors moving into this market. Indeed, companies with a SOC will likely find these vendors appealing because most of them also operate SOCs for the dynamic scanning part of the system.

    Still don’t have DevSecOps installed? Go now. Choose a vendor.

    Because I’m being so forceful about telling you to install one of these toolsets, I’ll state very clearly: At the time of this writing, I do not have any kind of relationship with any vendor in this space. I say this because I use the tools and strongly believe that the pain points they bring as a layer in development are very much made up for by the benefits they bring to the application.

    And keep rocking it. This will just make your systems more stable, and the merges (that I see as inevitable, but is actually only a possibility) you can worry about when they come along.

  • GitLab Allies With Rezilion to Add Workload Analysis Tool

    GitLab Allies With Rezilion to Add Workload Analysis Tool

    Rezilion has integrated its workload analysis tool with the continuous integration (CI) framework provided by GitLab. The move is part of an effort to make it simpler for developers to discover issues such as vulnerabilities before they upload code into a repository.

    Sam White, a senior product manager for GitLab, said this integration will provide developers with an instant feedback loop that will enable them to address a wide range of issues before their code is ever reviewed. Rather than experiencing the shame of, for example, missing a vulnerability, the Rezilion platform enables developers to quickly write code while relying on a code analytics tool to surface common mistakes that they can remediate as they see fit, he added.

    Rezilion CEO Liran Tancman added that the proprietary workload composition analysis engine, dubbed Unison, on which the Rezilion platform is based makes it feasible to shift more responsibility for application security further left without requiring developers to become cybersecurity experts.

    Unison automatically creates a model of all the applications that include the underlying infrastructure and runtime environments. It reverse-engineers and maps that environment in memory to dynamically track the inventory, provenance, runtime execution, exposure and interdependencies between each piece of code and can generate a software bill of materials (SBOM).

    The code that is most in need of immediate attention is also surfaced directly with the GitLab user interface, said Tancman. That capability can reduce remediation time of the vulnerability backlog an organization might be working through by as much as 70% over time, he added. Rezilion enables organizations to achieve that goal because non-exploitable vulnerabilities are marked as “false positives” that shouldn’t hold back a release.

    Tancman said that without this level of automation it would be extremely challenging for an organization to implement a set of DevSecOps best practices. It might take developers years to attain the level of cybersecurity training that would be required in the absence of the automation enabled by the Unison engine, he noted.

    Historically, the relationship between application developers and cybersecurity teams has been tense. Cybersecurity teams tend to put off code review until it’s about to be deployed in a production environment. It’s not uncommon for an application to be pulled at the last minute because of a vulnerability discovered by a cybersecurity team. In some instances, that vulnerability is a legitimate concern but in others, it turns out to be a false positive because the flagged piece of code isn’t actually included in the application.

    By providing developers with a workload composition analysis tool within the context of a CI framework, GitLab is trying to reduce the level of friction that the process tends to create between developers and cybersecurity teams.

    It may be some time before most organizations fully master DevSecOps, but it’s clear that merely telling developers they will be held accountable for application security without providing the appropriate tools isn’t going to make applications any more secure.

  • GrammaTech Adds SBOM Analysis Capability to CodeSentry

    GrammaTech Adds SBOM Analysis Capability to CodeSentry

    GrammaTech today updated its CodeSentry code inspection platform to include the ability to create a software bill of materials (SBOM) by analyzing application binaries.

    Walter Capitani, director of technical product management for GrammaTech, said version 3.0 of CodeSentry leverages the algorithms the company uses for binary software composition analysis to enable organizations to better address software supply chain concerns in the wake of a series of high-profile vulnerabilities.

    The tool can be applied to both commercial software and open source components via integration with Risk Based Security’s VulnDB database, created to track security issues.

    GrammaTech

    There is more focus than ever on creating SBOMs in the wake of the Biden administration’s recent executive order that will require federal agencies to only use software that comes with an SBOM. However, most organizations are not provided with access to the source code used within the applications they employ. GrammaTech enables organizations to address that issue by analyzing the binary code within an application to generate an SBOM.

    That report not only identifies all the components in an application, it also lists all known vulnerabilities associated with the version of the components being employed, said Capitani. CodeSentry will also list other common software products and the versions that may be impacted by the same vulnerabilities, along with versions of the software that have remediated the issue or versions of a component that have not been impacted by those vulnerabilities.

    Almost all software applications include third-party and open source components that create blind spots within software supply chains. In fact, that issue is what makes remediating zero-day application vulnerabilities so challenging; especially when they are discovered in, for example, a log management tool like Log4j that is widely used in Java applications.

    GrammaTech is making a case for a binary software composition analysis (SCA) tool that enables DevOps teams to address vulnerability issues prior to an application being deployed in a production environment. At the same time, however, security and compliance teams can now use the same tool to determine the level of risk an organization might be incurring once an application is deployed in production. That latter capability is especially critical because zero-day vulnerabilities are often not discovered until long after an application is deployed in a production environment, noted Capitani.

    Regardless of approach, the need to better secure software supply chains is now a major IT issue that should ultimately encourage more organizations to adopt DevSecOps best practices to better secure applications. The challenge, of course, is not just espousing the need for those practices but also providing developers with tools they will actually use to implement those practices. The success or failure of those efforts comes down to not just the efficacy of the tool but also how well it fits within the overall developer experience. After all, the greatest tool in the world will still languish if it’s too difficult for the average developer to employ.

  • The Risks and Potential Impacts Associated with Open Source

    The Risks and Potential Impacts Associated with Open Source

    Open source software (OSS) is built by communities of developers who contribute their knowledge and time to OSS projects they find appealing. That code can then be used by individuals, communities and organizations in their software products—the only obligation they have is to play under the rules of the license with which the OSS project was published. 

    This type of knowledge sharing brings many benefits to OSS users as it speeds up software development time and can help companies become more competitive in the market. Unfortunately, there is also a catch. Those benefits also come with certain risks which every OSS user needs to be aware of and take necessary actions to mitigate.

    The OSS License

    One specific risk to consider involves the OSS license. Not knowing what your obligations are under the license (or not abiding by those obligations) can cause an OSS user to, for example, lose intellectual property or experience a monetary loss.

    Operational Impact on the Product

    Another risk is the operational impact that the OSS in use will have on the product. It’s important to understand whether the community is consistently managing the OSS project and its issues in a timely manner, and that your organization has implemented the latest version and deployed patches have been applied. Using out-of-date, unpatched or unmaintained OSS could impact your release capabilities, product quality and customer trust.

    Security Vulnerabilities

    The third risk to consider when using OSS is that of security risk. As open source is software—and in many cases very complex software—it brings with it the possibility of introducing software security vulnerabilities into your source code. Some vulnerabilities can be introduced into your projects through dependencies that the OSS your organization is using has on other OSS projects. Additionally, vulnerabilities could be unintentionally introduced by developers as they code a functionality using open source. The reason for this is that software developers, whether professionals or hobbyists, oftentimes do not consider security while coding. This has a substantial impact on their work and their contributions to open source projects. 

    It’s not necessarily that developers intentionally skip the implementation of security procedures. Secure coding is a specific discipline in software development that guards against the accidental introduction of vulnerabilities—a discipline that must be learned. 

    Understand that many developers are self-taught or have been trained in schools and universities (where we are only recently seeing courses in software and application security emerging). Many use their software development skills as a hobby, to contribute to OSS projects or to pursue their own personal projects. Unfortunately, training programs, programming courses in schools and online tutorials often neglect to convey this knowledge or to stress the importance of building secure software. 

    It’s also important to note that many organizations find it difficult to introduce a secure coding discipline into their software development process. In other words, this struggle persists beyond open source projects. If you’re with an organization experiencing this pain point and unsure where to begin, you’ve come to the right place. There are several strategies that can be used to begin your secure coding journey. 

    Training

    By giving developers the education required for them to become security aware, you’re setting them up for consistent, secure development success. There are a variety of in-person and computer-based training options on the market.

    Software Composition Analysis (SCA) Tooling

    Implementing an SCA tool will uncover incorrectly coded strings or vulnerabilities that have been introduced in code or OSS components. Not only can SCA tools assist developers in identifying potential software risks, some SCA solutions can help to train developers by offering remediation guidance or short training videos on how to avoid such vulnerabilities in the future.

    It’s essential for software issues to be discovered early because the deeper into the process they’re identified, the more time-consuming and costly they are to remediate. As such, in recent years there has been a push to shift left, introducing security into the product development life cycle from the very beginning. 

    Companies and individuals need to also understand that this security mindset doesn’t start and end in the coding phase of the development process. A security mindset needs to be a part of every phase: from design to deployment to maintenance, all the way through to the product’s end of life. 

    Emphasizing a security mindset also has a long-term, broad reaching positive effects on the whole software development ecosystem, including the OSS world. As developers are trained to code securely (through university courses and other training institutions, coding portals or professional development through their employer) they pass this knowledge on to the projects with which they’re involved. This then leads to the production of higher quality proprietary and open source software, which in turn minimizes risk across the board.

    — Boris Cipot

  • The Challenge of Securing Open Source Applications

    The Challenge of Securing Open Source Applications

    As enterprises have increased their reliance on applications over the years, there has been a significant rise in the use of reusable software components such as third-party libraries and open source code. This makes perfect sense, as this development method makes it possible to add value to applications and other software offerings quickly and easily. After all, why reinvent the wheel when supposedly well-tested and proven software components are readily available?

    As a result, open source code has become a vital part of software development for most organizations. Today, nearly 70% of every application is comprised of reusable software components, including open source software. At one time, open source software was considered too risky for commercial use. That is not the case today, however, as even major corporations are making use of open source components to innovate and deliver applications to market rapidly.

    While enterprises have gotten very good at using open source to speed the application development process, they have not yet figured out how to do so without inadvertently introducing vulnerabilities into their code. This is due in part to the fact that as more enterprises increase reliance on applications, they fail to implement application security into the software development life cycle. Consequently, as the adoption of open source software continues to grow, the likelihood of applications inheriting vulnerabilities is higher than ever before.

    This is evidenced by the fact that, according to my company’s research, unpatched library vulnerabilities make up 21% of all application vulnerabilities, by far the most of any type. In fact, nearly 20% of the inquiries we answer are related to unpatched libraries, which is almost on par with injection vulnerabilities.

    That is why it is imperative for development teams to stay up-to-date with open source library maintenance and updates.

    Software Composition Analysis

    The right way for organizations to track their open source components is through a set of technologies known collectively as software composition analysis (SCA). These technologies, which arose out of a need to automate the open source management process, provide organizations with visibility into their open source inventory. This allows them to identify third-party and open source components integrated into their applications.

    Using SCA, organizations can determine easily if any of their applications are relying on a vulnerable library, if any libraries are out of date and whether licensing is legal/proper. SCA helps them identify multiple types of risk introduced by third-party and open source components. These can include known vulnerabilities, intellectual property risk and technical debt related to component age.

    It’s important to remember the use of open source software code is not a problem in and of itself. On the contrary, it has been an essential part of the recent innovations in software development, and, in fact, it is no riskier than proprietary or commercial off-the-shelf offerings.

    Problems arise only when organizations fail to be proactive in identifying and managing security and license risks associated with open source code. This may occur in part because it is assumed that, as with commercial software, updates, patches and information are pushed to the user. But that’s not the case in the open source world, where the onus is on the user to keep track of these things.

    It takes diligence, but in the end, the only way to mitigate both the security and legal risks associated with your open source code—and to fully realize its benefits—is to track every piece of it. Today, SCA is the proven way to help you do that. By incorporating SCA into the development process, developers can capture inherited vulnerabilities early enough to prevent them from being introduced. Of course, it should go without saying, but it’s not enough to just find vulnerabilities; you also must fix them. The most typical remediation is replacing vulnerable components with the non-vulnerable ones.

    Considering most application code is now open source, and attackers are going after vulnerabilities in open source more than ever before, SCA should not be an afterthought. It needs to be an integral part of any organization’s application security and secure DevOps processes.

    — Joseph Feiman