I share a birthday with the Log4j event. However, unlike this event, I’ve been around for more than one year. On December 9th, 2021, a Tweet exposed a zero-day vulnerability in Log4j, a widely-used piece of open-source software. The announcement made headlines everywhere, and cybersecurity was suddenly put in the spotlight. It was a wake-up call for many because, in an instant, software that had been considered secure was suddenly at tremendous risk.

The Sysdig Threat Research Team (TRT) recently discovered threat actors leveraging an open source tool called PRoot to expand the scope of their operations to multiple Linux distributions and simplify their necessary efforts. Typically, the scope of an attack is limited by the varying configurations of each Linux distribution. Enter PRoot, an open source tool that provides an attacker with a consistent operational environment across different Linux distributions, such as Ubuntu, Fedora, and Alpine.

Testing practices have been shifting left in the software development process due to the growing challenge of developing and delivering high-quality, secure software at today’s competitive pace. Agile methodologies and the DevOps approach were created to address these needs. In this post, we’ll map out the basics of shift-left practices in the DevOps pipeline and discuss how to shift left your open source security and compliance testing. Contents hide 1 What does shift left mean?

See examples of custom and variant licenses and how Black Duck Audits flag these licenses to help legal teams evaluate software risk. An open source audit reveals much about modern software. A thorough one will draw attention to license issues that go beyond typical open source license conflicts. The baseline finding of an audit is a complete, accurate software Bill of Materials (SBOM) of open source and third-party software in the code.

Black Duck Security Advisories provide more-accurate information on vulnerable software version ranges to help customers get more out of NVD data.

Understanding the differences between an open source audit and an open source scan will help you determine which approach is best for your organization.

For far too long, the cybersecurity industry has subscribed to a flawed methodology — one that is based on the notion that organizations can avoid security threats through obscurity and secrecy. The assumption is that keeping security controls and processes covert makes products and data inherently more secure against cyber threats within the networks we defend. However, even the most sophisticated cybersecurity defenses are no match for well-funded, highly motivated adversaries.

The awaited OpenSSL 3.0.7 patch was released on Nov. 1. The OpenSSL Project team announced two HIGH severity vulnerabilities (CVE-2022-3602, CVE-2022-3786), which affect all OpenSSL v3 versions up to 3.0.6. These vulnerabilities are remediated in version 3.0.7, which was released Nov. 1. The vulnerabilities fixed include two stack-based buffer overflows in the name constraint checking portion of X.509 certificate verification.