devopsy.kinsta.cloud

Tag: Source Code Analysis

  • DevSecOps Implementation: Source Composition Analysis

    DevSecOps Implementation: Source Composition Analysis

    This is the second installment in this series on DevSecOps. Read the first installment, on Static Analysis, here.

    One of the better additions to security in recent years is source composition analysis (SCA). The purpose of SCA is to sit in the gap between static analysis and dynamic analysis to help you find issues introduced by included libraries, projects, etc. While effective, source composition analysis is only available on open source libraries and packages, which are the highest growth areas of external sources in any project. If we are purchasing a product to include in our application, we take our time and compare and contrast to make certain we have the right thing. If there is an open source option, we just drop it in. Particularly if the option is popular—little thought goes into using MySQL database in Python or its equivalent in other languages. If a Python project uses MySQL or MariaDB, it is needed, so it is grabbed and used.

    The growth of source composition analysis is a great boon to security. Having a tool that takes care of monitoring vulnerabilities in code that is included across the board, sometimes in very uncontrolled ways, means vulnerabilities are known before the app goes live or the new release is published. Security staff doesn’t have to try to ferret out what is included in projects across the org and then cross-reference those findings with the National Vulnerability Database (NVD) or project-specific lists. The tool takes a load off security’s shoulders and makes certain developers know the risks their open source software (OSS) usage represents. The best tools notify developers when including vulnerable open source and can be configured to require approval before a vulnerable OSS library/module can be included.

    With all of that said, let’s talk about what to look for. There are some similarities with our static analysis list, but some distinct differences also. Disclaimer: As mentioned in the Static Analysis blog, this is very high-level. The research we’ve done at Accelerated Strategies Group went much deeper than we can present in a series of blogs; this is just to help you understand the top-level issues and get started down the road to a solid DevSecOps plan:

    • Language Support: This goes beyond most users’ needs in static analysis. One of open source’s strengths is building off other projects. It is often the case that Python will call C modules and some Python projects even include Go libraries. This means your chosen development tools aren’t so much relevant for scanning as the development tools chosen by projects—and their included projects.
    • Depth of Checking: Which brings us to, “How deep does the tool go?” Nesting of open source libraries can be deep and complex, with the project an application uses directly just the tip of the ice-berg. Ideally, look for a tool that answers the, “Is this even ever called?” question. It’s a good start to alert on included OSS projects and it is far better to alert on ones where the vulnerable parts are called from somewhere in the hierarchy.
    • Where to Run: The market is slowly moving to support both cloud-based and local scans. Make certain your organization’s needs are met by the vendor’s offerings.
    • When to run: Some vendors bundle source composition analysis in with their static analysis IDE plugins; others have developers run the scan command line; others offer source composition analysis at the build step—when the app is together in one place; still others offer all of the above. Again, make certain the needs of your organization are met.
    • What Is Detected: As with most security tools, this is normally a base comprised of public sources (NVD, OWASP), with add-on detection from other sources. Know what those other sources are and what they offer: that is one major difference between most products.
    • Reporting: Make certain that vulnerability reporting has everything you need. Consider the possibility that it alerts on a vulnerable OSS library in source file insecure.go. All other uses of that vulnerability need to be visible in some way from that report. Removing the reference from insecure.go is useless if reallyinsecure.go also includes it and has an exception from management to keep the inclusion.
    • Reporting Integration: While scanning OSS usage and vulnerabilities the usage introduces is important, so also is the ability to see these results side by side with static, dynamic and even interactive scans so the overall security posture of the application can be evaluated.
    • Frequency Versus Cost: OSS vulnerabilities come in unpredictable patterns, with several dropped in a week after no important ones were seen the week before. You are going to want to run these scans frequently enough to feel comfortable with your security posture, but depending upon licensing, each run might cost your company money. Make sure you understand your needs and costs associated with meeting them.
    • Licensing: The newest feature to be added to these tools is the ability to list all licenses of all included libraries so that someone can review and see what risk is introduced to the organization from licensing. Many open source projects are licensed so that commercial use is limited; this tool puts all the various licenses together so an organization can evaluate litigation risk based upon license usage. The best tools allow you to also enter proprietary license information so that all licensing relevant to an application is reviewed together.

    These tools help improve security posture by automating what is an increasingly complex manual process and bringing in vulnerability sources that security (be they secure developers or dedicated security staff) would have to manually look for. They enable shifting OSS vulnerability resolution left, allowing your team to become more agile and proactive. Make certain the tool chosen is the right one for the organization.

    As I said in the last installment, you all are keeping the lights on in a truly difficult time, making a tough job look easy. Don’t let vulnerabilities that can be caught easily with these tools but might stay hidden without stop your great work. They are relatively easy to install and configure; once you have them, you have on-demand OSS vulnerability scanning and if you are like most organizations, OSS is a huge piece of your software infrastructure. Keep rocking it, and make sure you are covered for OSS vulnerabilities and licensing.

  • DevSecOps Implementation: Static Analysis

    DevSecOps Implementation: Static Analysis

    One of the things I’ve done for Accelerated Strategies Group recently is looking into DevSecOps toolsets. This is a fun area for me, as development and security fit together well in my mind. Having a separate security group is useful, even necessary in some scenarios, but letting developers crank out code and looking for vulnerabilities only after has always seemed terribly inefficient. Whenever I’ve managed developers, security training is just part of the package I bring. It’s far easier to write it well the first time (the equivalent of shift-left) than rewrite it.

    I won’t name names here—this is work I did for ASG, it is not mine to give away—but I will talk about DevSecOps today, and moving into the future. I’m planning three to four installments for this series, discussing the different aspects of DevSecOps tools.

    For clarity, we’re defining DevSecOps tools as “developer-enabled security tools.” This means that in some way, they help developers improve overall security posture while leaving them to be developers. We all know security has to shift left in every way if it’s to be useful in a DevOps world, but most organizations haven’t seriously started the move to shift security. Hopefully, this series helps.

    Depending upon which financial analyst firm you prefer, projections are that the DevSecOps market will grow 28% to 33% a year for the next few years. While this is good news for DevSecOps vendors, it implies very few organizations have systemically adopted DevSecOps, or there would not be room for that level of growth.

    Whether a traditional team or a DevOps team, the static analysis portion of DevSecOps is (generally) easy to set up and configure and most products offer feedback at both coding time and build time. IDE plugins have come a long way, some even offering advice as-you-code and others allowing developers to run on-demand static scans of their work. The industry as a whole has worked hard to lower the false-positive rates that made most organizations reluctant to deploy them broadly, and prioritization of issues is possible in the best products, making identification and remediation pretty easy. Try a pilot out: Pick a vendor and project, grab the IDE plug-in and check out what they can do. Most do not yet directly support code smells, but I suspect that is coming rapidly, as the systems are already designed to look at source and determine issues. Adding to the collection of possible issues will be a differentiator that quickly turns into a market requirement.

    Things to check for:

    • Language support: Do the languages you use have a scanner? While most of the tools on the market offer support for a breadth of languages, there are differences, so check the corner cases. This truly is a make or break decision—the best product on the market is useless to your org if it doesn’t support the languages you use.
    • IDE integration: This is pretty straightforward, are the IDEs your developers use day in and day out supported? Most of these tools offer command-line variants also, so it is possible that even without support directly in the IDE, the security functionality of a given product dictates that command-line is better. In that scenario, a process to ensure developers are even running scans is a good idea.
    • Vulnerabilities detected: At a minimum, support for whatever is currently in the National Vulnerability Database (NVD) should be required, along with OWASP compliance. Most vendors offer support beyond the NVD, so a bit of research to see what types of vulnerabilities are detected will be in order.
    • Click-through support: With IDE plug-ins, one of the great strengths of scanning is the ability of the developer to simply click on the vulnerability in the results list and go to the offending code. Make certain this works—and works as advertised.
    • False-positive rate: This has historically been a problem, but the industry has brought it down overall. Ask your prospective vendors to share their numbers. Our experience shows low single-digits for a percent, which is far better than the past, but still leaves room for improvement.

    The other part of static analysis is plugging static analysis into the build process. Most of these products have integrations into the most popular build management tools. Scanning the entirety of the application allows the static analysis to see a broader vision of the app and note issues with interactions between portions written by different developers. Reporting for build-time scans is generally at the application/team level, and the best tools will show results of development-time scans side by side with build-time scans if you want them to.

    Things to check for:

    • Language support: Again with the languages. It’s pretty simple here: The core of the application may be built using languages a given vendor supports but critical parts might not. Integration is where that becomes a real issue. Make sure what needs scanning can get scanned.
    • Integrations: Most of these tools offer automated scans through integration with build tools or manual scans that the build manager can kick off. Automation is preferred by a long shot, so check if your tool of choice is integrated into your organization’s build tooling.
    • Depth: We’re not going to get into source composition analysis (SCA) here—that’s for another blog—but we are going to observe that vulnerabilities can come from your source’s sources. How far does the scanning tool trace in a static analysis situation? Is it deep enough to cover a given application’s integrations and inter-relationships? While SCA will detect a lot that static scanning won’t, things such as “unsafe values sent to [insert external API]” should be available in static code analysis.
    • Reporting: This is where you’ll find the most variety in popular tools. Look at their reporting and click-through support to find what best suits your needs.
    • False-positive rate: Same as IDE integrations above—make certain it is low enough for your organization’s comfort.
    • Scan run location: This is becoming a differentiator in the space—do you want your scans run in the cloud? In the data center? Some mix of both? Check your vendors; there are significant differences in the level of support for these options.

    This is just the tip of the iceberg, of course. It is an entire market segment, and static analysis tools have been around a long time. Many organizations have not taken dev-time security seriously yet, even though we all know we need to; I’m just offering a place to get started.

    DevSecOps just makes sense. Static scanning is mature and generally well-integrated. This is a great place to start shifting security left. We get it: Developers don’t want to be security analysts or they’d have filled one of those many security openings. But IDE integration makes these scanning tools more interactive and less intrusive, showing developers how to do it securely as they code. This is great to me because good coding practices will become second nature with real-time, on-the-spot reminders and pointers. It also means that if the developer acts upon the tool’s recommendations, the code is developed more securely the first time and there will be no need to revisit it for security proofing.

    You’re all keeping the lights on in a terribly tough time. DevSecOps attempts to make it more likely that your astounding work isn’t interrupted. It just makes sense to get these tools to protect your organization’s portfolio and your hard work.

  • New Survey Highlights Codebase Size Problems

    New Survey Highlights Codebase Size Problems

    Sourcegraph and Dimensional Research have released a survey of developers at large organizations, which shows a massive growth in codebase size, number of repositories in use and complexity concerns.

    “The Emergence of Big Code – A 2020 Survey of Software Professionals” is definitely intriguing reading, and a few of the results are eye-opening—such as the difference between what development managers think developers are using to search code and what developers say they are actually using. But most of it simply validates what we all knew: Codebases are growing at an alarming rate, through a variety of growth vectors—support for new platforms, use of open source and internal development. Adding environment to code à la GitOps, systems reliability engineering and/or environment automation is adding a layer of completely new source and a layer of complexity not normally in the developer’s realm of immediate concern.

    I’ve been working with Accelerated Strategies Group over the last few months, and we’re looking at tools in this market. The ability to quickly get up to speed on large codebases and the ability to find a specific area in a codebase that is massive and/or spans repositories is a very real need that is not currently well-served. This piques my interest in what Sourcegraph brings to the table, but at the moment we’re focused on the survey, so perhaps in a future blog we’ll talk about Sourcegraph.

    While there is a lot packed into the survey, I think my favorite part is crammed in with other “What would you find useful?” results (the slide is below). Fifty-eight percent of respondents—all of whom are developers—chose, “Finding code by querying semantic relationships, not just matching a string.” As developers, these respondents no doubt are aware of the complexities of this type of feature, particularly in environments with a variety of programming languages and scripts (be they bash, SQL, whatever) all working together. This is huge, and first iterations would be shallow, but is a worthy goal. I’m intrigued to see how well SourceGraph et al solve it.

    Source: The Emergence of Big Code – A 2020 Survey of Software Professionals

    It is also intriguing to see more than half of respondents want the ability to explore ” … both known and unknown code with code intelligence that provides contextual understanding.” That, too, is a tall order. Code analysis has gotten better over time, but contextual analysis of large codebases is notoriously difficult. I’ll be intrigued in the near future to play with this concept and tools that offer it to see how reliable they are and how much human guidance is accepted and/or required to make it a reality.

    Code change velocity reporting and contextual information about code are both available and pretty solid from the majority of full-stack DevOps vendors. Perhaps that is why that particular response only netted 45% and 43% of responses, respectively—the other 50+% are already using them.

    We’re in an interesting time when consolidation appears to be on the upswing and the needs of developers and DevOps teams working in large codebases are becoming more clear and more complex at the same time. Over the next few years the needs reported in this survey will likely be replaced by more specific needs as these are fulfilled and find general use. The question of databases and database integration in large codebase migrations, for example, has these needs, but has other needs closer to the problem domain. As these general issues are resolved, expect your vendors to turn to those more specific, but every bit as complex, problems.

    And just keep rocking it. Find out what the tools and companies already in use at your org have added, and if those capabilities fit with your needs or can enhance your Dev/DevOps exercises. Keep the lights on, keep customers happy and watch for tools to help you make it even better.