devopsy.kinsta.cloud

Tag: code-scanning tool

  • Snyk Extends Tools Portfolio to Drive DevSecOps Adoption

    Snyk Extends Tools Portfolio to Drive DevSecOps Adoption

    During its online SnykCon 2021 conference this week, Snyk extended Snyk Code, a static application security testing (SAST) tool that already supports the Java, JavaScript and Python programming languages to include support for C#, Ruby, PHP and Go.

    At the same time, Snyk Open Source, a platform for remediating open source vulnerabilities, has been extended to provide native integration with Atlassian BitBucket and AWS CodePipeline platforms for driving DevOps workflows. Snyk has also tightened integrations with platforms from DigitalOcean and HashiCorp.

    Snyk also added support for the Elixir programming language and package managers Yarn 2 and Poetry alongside integration with a C++ scanning tool from FossilID, a provider of a software composition analysis (SCA) tool for open source code that Snyk acquired earlier this year.

    The Snyk Container platform is now integrated with the open source Trivy container scanning tools and with Snyk’s vulnerability database in addition to adding support for container registries such as Quay, GitHub Container Registry, GitLab, Google Artifact Registry and Harbor.

    The Snyk infrastructure-as-code platform now also makes it possible to detect configuration issues in Kubernetes manifests in Terraform code in a way that is compatible with cloud platforms from Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).

    Snyk also is adding support for version 3 of OpenAPI, which the company reports is three times faster than the previous version. That API is also the foundation for Snyk Apps that the company will continue to roll out.

    Finally, Snyk launched both a new free developer security education program, dubbed Snyk Learn, through which developers can attain and measure their level of DevSecOps expertise and Snyk Impact, an effort to foster collaboration among developers involving a wide range of socio-economic issues.

    Company president Guy Podjamy said as DevsecOps continues to evolve, the primary focus remains on developers and DevOps teams. However, as an issue, DevSecOps is also becoming more important at both the C-level within organizations as well as individual security operations teams. As such, and in the wake of recent high-profile security breaches, the sense of urgency surrounding DevSecOps is now a lot higher. The fundamental challenge organizations are trying to address is finding a way to improve overall application security without slowing down the pace at which applications are built, noted Podjamy.

    Snyk itself revealed it has secured an additional $530 million round of funding to address those issues. The company has now raised a total of $775 million to date with a valuation of $8.5 billion. Snyk also revealed it has increased annual recurring revenue (ARR) by 154% year-over-year from a customer base that now spans more than 1,200 organizations, including Asurion, Google, Intuit, MongoDB, New Relic, Revolut and Salesforce. Snyk customers and users collectively have run more than 300 million tests in the last 12 months to fix more than 30 million vulnerabilities in a 90-day period of time, the company claims.

    It may be a while before most organizations have embedded security tools within every DevOps workflow. However, given the resources being poured into DevSecOps, it may be more a question when DevSecOps will be finally achieved rather than if.

  • Yes, You Do Need SCA

    Yes, You Do Need SCA

    We often go to restaurants and treat ourselves to unfamiliar and exotic foods made with ingredients we’re only vaguely aware of. A chef and their team (or a manager and their crew) are our vouchsafe that what’s in there isn’t deadly. Most of the time, that works out just fine; but, very rarely, we end up paying the price. The same is true for food brought home from the supermarket, though for lesser illnesses it is harder to track because they’re not clustered like restaurant customers. While it is indeed exceedingly rare for the results to be fatal, the CDC estimates that around 3,000 people die of food-borne illnesses in the U.S. each year, and millions more are made ill. The U.S. has incredibly safe foods, and yet, we still have these illnesses. Simple things like leaving ingredients out too long, or consuming food sourced from a contaminated production facility can cause problems, even in an otherwise safe environment.

    Our code is similar—how it is created and consumed—and increasingly falls in this category. We rely upon a ton of sources for the systems that run our networks, and, quite often, there is no one to tell us how safe our sourcing is, or if changes are happening beneath that escape our notice.

    This is why we absolutely must have software composition analysis (SCA). If no one else is going to stand up and verify the safety of all that code we are pulling in, then we need to at least be aware of what is there. We need to understand the inter-relationships of pieces of underlying software, both the known and the unknown. Some libraries are so ubiquitous that you are using them and likely don’t even know it. But that’s not good management; knowing what you have and taking care of it are increasingly becoming a core part of IT. Knowing what alternatives are available in case something goes wrong with your preferred (or automatic) inclusion is imperative for continuity, making SCA a critical part of continuity planning along with the fact that it’s just good business practice.

    The good news is, if you are using any of the major code scanning tools from the DevSecOps space, you either already have SCA available to you, or you can buy it as an add-on from the same vendor. Hit their website and find out.

    Your systems are out there, every day, serving the needs of your users. Protect those users from unforeseen circumstances like vendor issues, open source changes, security vulnerabilities and nested dependencies. While the vast majority of open source is safe and secure, we use so much of it—and the tools we use link in so much of it—that it’s almost certain there is a bomb hidden somewhere in your code. Think of it like the food-borne illness example above: Would you eat at a restaurant that said “Yeah, 90% of our food is safe, but we’re not sure about the other 10% …”?

    You’re building astounding things, and keeping the world moving. Don’t stop, but don’t let your guard down, either. Know what is running in those apps, what its vulnerabilities (both security and downtime) are and what you can do to mitigate those weaknesses–so you can keep making astounding things rather than spend your time fixing what is already there.

  • GitHub Delivers on Code Scanning Promise

    GitHub Delivers on Code Scanning Promise

    GitHub today announced it is now making available at no cost the open source CodeQL code scanning tool it gained by acquiring Semmle.

    Justin Hutchings, a product manager at GitHub, said the goal is to further adoption of best DevSecOps practices by making it easy for developers to scan for vulnerabilities as they check code in and out of the GitHub repository. It is also designed to be integrated with either GitHub Actions or an existing continuous integration/continuous delivery (CI/CD) platform to enable DevOps teams to create workflows that include code scans, he said.

    For private repositories, code scanning is part of the GitHub Advanced Security suite of tools GitHub makes available via GitHub Enterprise.

    Code scanning also makes it possible to integrate third-party scanning engines via support for the Static Analysis Results Interchange Format (SARIF), which provides a standard for sharing data between SAST tools via a common application programming interface (API). GitHub has thus far partnered with more than a dozen open source and commercial security vendors to allow developers to run code scanning within their offerings, noted Hutchings.

    GitHub claims since it made CodeQL available in beta last May, it has scanned more than 12,000 repositories more than 1.4 million times and found more than 20,000 security issues involving everything from remote code execution (RCE) and SQL injection to cross-site scripting (XSS) vulnerabilities.

    Developers and maintainers fixed 72% of reported security errors identified in their pull requests before merging in the last 30 days alone, reported GitHub. Hutchings noted those efforts represent a major step forward for DevSecOps, given the fact that industry data shows that less than 30% of all flaws are fixed one month after discovery.

    GitHub, along with the open source CodeQL community, has also created more than 2,000 CodeQL queries that DevSecOps teams can employ to scan code for specific types of vulnerabilities. GitHub also noted there already have been 132 community contributions to the CodeQL open source query set.

    Given how nascent best DevSecOps practices are in most organizations, simply making SAST tools available to developers is often a major step forward for many organizations. The challenge has been finding SAST tools that developers want to employ, said Hutchings. Most SAST tools were designed for security teams rather than developers. CodeQL is designed to surface vulnerabilities in a way that makes it clear where developers need to prioritize their remediation efforts, he noted.

    It’s not clear yet to what degree responsibility for security will shift left toward developers. There will always be a need for cybersecurity teams to verify that the proper controls are in place. However, as DevOps teams assume responsibility for security it’s almost certain they will do so on their own terms. The days when cybersecurity teams select the security tools that developers are expected to employ are now all but over.