Microsoft releases guidance on how organizations can check their systems for the presence of BlackLotus, a powerful threat first analyzed by ESET researchers

The post Hunting down BlackLotus – Week in security with Tony Anscombe appeared first on WeLiveSecurity

Posted by Julie Qiu, Go Security & Reliability and Oliver Chang, Google Open Source Security Team

High profile open source vulnerabilities have made it clear that securing the supply chains underpinning modern software is an urgent, yet enormous, undertaking. As supply chains get more complicated, enterprise developers need to manage the tidal wave of vulnerabilities that propagate up through dependency trees. Open source maintainers need streamlined ways to vet proposed dependencies and protect their projects. A rise in attacks coupled with increasingly complex supply chains means that supply chain security problems need solutions on the ecosystem level.

One way developers can manage this enormous risk is by choosing a more secure language. As part of Google’s commitment to advancing cybersecurity and securing the software supply chain, Go maintainers are focused this year on hardening supply chain security, streamlining security information to our users, and making it easier than ever to make good security choices in Go.

This is the first in a series of blog posts about how developers and enterprises can secure their supply chains with Go. Today’s post covers how Go helps teams with the tricky problem of managing vulnerabilities in their open source packages.

Extensive Package Insights

Before adopting a dependency, it’s important to have high-quality information about the package. Seamless access to comprehensive information can be the difference between an informed choice and a future security incident from a vulnerability in your supply chain. Along with providing package documentation and version history, the Go package discovery site links to Open Source Insights. The Open Source Insights page includes vulnerability information, a dependency tree, and a security score provided by the OpenSSF Scorecard project. Scorecard evaluates projects on more than a dozen security metrics, each backed up with supporting information, and assigns the project an overall score out of ten to help users quickly judge its security stance (example). The Go package discovery site puts all these resources at developers’ fingertips when they need them most—before taking on a potentially risky dependency.

Curated Vulnerability Information

Large consumers of open source software must manage many packages and a high volume of vulnerabilities. For enterprise teams, filtering out noisy, low quality advisories and false positives from critical vulnerabilities is often the most important task in vulnerability management. If it is difficult to tell which vulnerabilities are important, it is impossible to properly prioritize their remediation. With granular advisory details, the Go vulnerability database removes barriers to vulnerability prioritization and remediation.

All vulnerability database entries are reviewed and curated by the Go security team. As a result, entries are accurate and include detailed metadata to improve the quality of vulnerability scans and to make vulnerability information more actionable. This metadata includes information on affected functions, operating systems, and architectures. With this information, vulnerability scanners can reduce the number of false positives using symbol information to filter out vulnerabilities that aren’t called by client code.

Consider the case of GO-2022-0646, which describes an unfixed vulnerability present in all versions of the package. It can only be triggered, though, if a particular, deprecated function is called. For the majority of users, this vulnerability is a false positive—but every user would need to spend time and effort to manually determine whether they’re affected if their vulnerability database doesn’t include function metadata. This amounts to enormous wasted effort that could be spent on more productive security efforts.

The Go vulnerability database streamlines this process by including accurate affected function level metadata for GO-2022-0646. Vulnerability scanners can then use static analysis to accurately determine if the project uses the affected function. Because of Go’s high quality metadata, a vulnerability such as this one can automatically be excluded with less frustration for developers, allowing them to focus on more relevant vulnerabilities. And for projects that do incorporate the affected function, Go’s metadata provides a remediation path: at the time of writing, it’s not possible to upgrade the package to fix the vulnerability, but you can stop using the vulnerable function. Whether or not the function is called, Go’s high quality metadata provides the user with the next step.

Entries in the Go vulnerability database are served as JSON files in the OSV format from vuln.go.dev. The OSV format is a minimal and precise industry-accepted reporting format for open source vulnerabilities that has coverage over 16 ecosystems. OSV treats open source as a first class citizen by including information specific to open source, like git commit hashes. The OSV format ensures that the vulnerability information is both machine readable and easy for developers to understand. That means that not only are the database entries easy to read and browse, but that the format is also compatible with automated tools like scanners. Go provides such a scanner that intelligently matches vulnerabilities to Go codebases.

Low noise, reliable vulnerability scanning

The Go team released a new command line tool, govulncheck, last September. Govulncheck does more than simply match dependencies to known vulnerabilities in the Go vulnerability database; it uses the additional metadata to analyze your project’s source code and narrow results to vulnerabilities that actually affect the application. This cuts down on false positives, reducing noise and making it easier to prioritize and fix issues.

You can run govulncheck as a command-line tool throughout your development process to see if a recent change introduced a new exploitable path. Fortunately, it’s easy to run govulncheck directly from your editor using the latest VS Code Go extension. Users have even incorporated govulncheck into their CI/CD pipeline. Finding new vulnerabilities early can help you fix them before they’re in production.

The Go team has been collaborating with the OSV team to bring source analysis capabilities to OSV-Scanner through a beta integration with govulncheck. OSV-Scanner is a general purpose, multi-ecosystem, vulnerability scanner that matches project dependencies to known vulnerabilities. Go vulnerabilities can now be marked as “unexecuted” thanks to govulncheck’s analysis.

Govulncheck is under active development, and the team appreciates feedback from users. Go package maintainers are also encouraged to contribute vulnerability reports to the Go vulnerability database.

Additionally, you can report a security bug in the Go project itself, following the Go Security Policy. These may be eligible for the Open Source Vulnerability Rewards Program, which gives financial rewards for vulnerabilities found in Google’s open source projects. These contributions improve security for all users and reports are always appreciated.

Security across the supply chain

Google is committed to helping developers use Go software securely across the end-to-end supply chain, connecting users to dependable data and tools throughout the development lifecycle. As supply chain complexities and threats continue to increase, Go’s mission is to provide the most secure development environment for software engineering at scale.

Our next installment in this series on supply chain security will cover how Go’s checksum database can help protect users from compromised dependencies. Watch for it in the coming weeks!

Posted by Jesper Sarnesjo and Nicky Ringland, Google Open Source Security Team

Today, we are excited to announce the deps.dev API, which provides free access to the deps.dev dataset of security metadata, including dependencies, licenses, advisories, and other critical health and security signals for more than 50 million open source package versions.

Software supply chain attacks are increasingly common and harmful, with high profile incidents such as Log4Shell, Codecov, and the recent 3CX hack. The overwhelming complexity of the software ecosystem causes trouble for even the most diligent and well-resourced developers.

We hope the deps.dev API will help the community make sense of complex dependency data that allows them to respond to—or even prevent—these types of attacks. By integrating this data into tools, workflows, and analyses, developers can more easily understand the risks in their software supply chains.

The power of dependency data

As part of Google’s ongoing efforts to improve open source security, the Open Source Insights team has built a reliable view of software metadata across 5 packaging ecosystems. The deps.dev data set is continuously updated from a range of sources: package registries, the Open Source Vulnerability database, code hosts such as GitHub and GitLab, and the software artifacts themselves. This includes 5 million packages, more than 50 million versions, from the Go, Maven, PyPI, npm, and Cargo ecosystems—and you’d better believe we’re counting them!

We collect and aggregate this data and derive transitive dependency graphs, advisory impact reports, OpenSSF Security Scorecard information, and more. Where the deps.dev website allows human exploration and examination, and the BigQuery dataset supports large-scale bulk data analysis, this new API enables programmatic, real-time access to the corpus for integration into tools, workflows, and analyses.

The API is used by a number of teams internally at Google to support the security of our own products. One of the first publicly visible uses is the GUAC integration, which uses the deps.dev data to enrich SBOMs. We have more exciting integrations in the works, but we’re most excited to see what the greater open source community builds!

We see the API as being useful for tool builders, researchers, and tinkerers who want to answer questions like:

• What versions are available for this package?
• What are the licenses that cover this version of a package—or all the packages in my codebase?
• How many dependencies does this package have? What are they?
• Does the latest version of this package include changes to dependencies or licenses?
• What versions of what packages correspond to this file?

Taken together, this information can help answer the most important overarching question: how much risk would this dependency add to my project?

The API can help surface critical security information where and when developers can act. This data can be integrated into:

• IDE Plugins, to make dependency and security information immediately available.
• CI/CD integrations to prevent rolling out code with vulnerability or license problems).
• Build tools and policy engine integrations to help ensure compliance.
• Post-release analysis tools to detect newly discovered vulnerabilities in your codebase.
• Tools to improve inventory management and mystery file identification.
• Visualizations to help you discover what your dependency graph actually looks like:
  

  Unique features

  The API has a couple of great features that aren’t available through the deps.dev website.

  Hash queries

  A unique feature of the API is hash queries: you can look up the hash of a file’s contents and find all the package versions that contain that file. This can help figure out what version of which package you have even absent other build metadata, which is useful in areas such as SBOMs, container analysis, incident response, and forensics.

  Real dependency graphs

  The deps.dev dependency data is not just what a package declares (its manifests, lock files, etc.), but rather a full dependency graph computed using the same algorithms as the packaging tools (Maven, npm, Pip, Go, Cargo). This gives a real set of dependencies similar to what you would get by actually installing the package, which is useful when a package changes but the developer doesn’t update the lock file. With the deps.dev API, tools can assess, monitor, or visualize expected (or unexpected!) dependencies.

  API in action

  For a demonstration of how the API can help software supply chain security efforts, consider the questions it could answer in a situation like the Log4Shell discovery:

  • Am I affected? – A CI/CD integration powered by the free API would automatically detect that a new, critical vulnerability is affecting your codebase, and alert you to act.
  • Where? – A dependency visualization tool pulling from the deps.dev API transitive dependency graphs would help you identify whether you can update one of your direct dependencies to fix the issue. If you were blocked, the tool would point you at the package(s) that are yet to be patched, so you could contribute a PR and help unblock yourself further up the tree.
  • Where else? – You could query the API with hashes of vendored JAR files to check if vulnerable log4j versions were unexpectedly hiding therein.
  • How much of the ecosystem is impacted? – Researchers, package managers, and other interested observers could use the API to understand how their ecosystem has been affected, as we did in this blog post about Log4Shell’s impact.

  Getting started

  The API service is globally replicated and highly available, meaning that you and your tools can depend on it being there when you need it.

  It’s also free and immediately available—no need to register for an API key. It’s just a simple, unauthenticated HTTPS API that returns JSON objects:

  # List the advisories affecting log4j 1.2.17
  $ curl https://api.deps.dev/v3alpha/systems/maven/packages/log4j%3Alog4j/versions/1.2.17 \
          | jq '.advisoryKeys[].id'
  "GHSA-2qrg-x229-3v8q"
  "GHSA-65fg-84f6-3jq3"
  "GHSA-f7vh-qwp3-x37m"
  "GHSA-fp5r-v3w9-4333"
  "GHSA-w9p3-5cr8-m3jj"

  
  A single API call to list all the GHSA advisories affecting a specific version of log4j.

  Check out the API Documentation to get started, or jump straight into the code with some examples.

  

  Securing supply chains

  Software supply chain security is hard, but it’s in all our interests to make it easier. Every day, Google works hard to create a safer internet, and we’re proud to be releasing this API to help do just that, and make this data universally accessible and useful to everyone.

  We look forward to seeing what you might do with the API, and would appreciate your feedback. (What works? What doesn’t? What makes it better?) You can reach us at depsdev@google.com, or by filing an issue on our GitHub repo.

In a rush to file your taxes? Watch out for cybercriminals preying on stressed taxpayers as Tax Day looms large on the horizon.

The post Steer clear of tax scams – Week in security with Tony Anscombe appeared first on WeLiveSecurity