Overview The internet is abuzz with the disclosure of CVE-2022-22965, an RCE vulnerability in Spring, one of the most popular open-source frameworks for Java applications in use today. Known as “Spring4Shell” or “SpringShell”, the zero-day vulnerability has triggered widespread concern about the possibility of a wave of malicious attacks targeting vulnerable applications. Is this Log4j 2.0?

Many Static Application Security Testing (SAST) tools struggle with false positives. They often report that a vulnerability is present, while, in reality, it does not exist. This inaccuracy weighs down the engineering team, as they spend productive hours triaging the false alarms. By setting a benchmark of false positives — a limit, above which is unacceptable — you can establish a point of reference or standard against which to measure the efficacy of your SAST tool.

Static application security testing (SAST) tools automatically scan the source code of an application. The goal is to identify vulnerabilities before deployment. SAST tools perform white-box testing, which involves analyzing the code based on inside knowledge of the application. SAST offers granularity in detecting vulnerabilities, providing an assessment down to the line of code.

Static Application Security Testing (SAST) is an effective and well-established application security testing technology. It allows developers to create high-quality and secure software that is resistant to the kinds of attacks that have grown more prevalent in recent years. However, the challenge with SAST is that it tends to produce a high number of false positives that waste the time of your engineering team. In this blog we take a look at SAST and the problem of false positives.

Software supply chain attacks are on the rise – the attacks increased by more than 600% between 2020 and 2021. On RubyGems, the official package repository for the Ruby programming language, attackers usually take advantage of the implicit trust developers have on the gems deployed on the platform and infect them with malicious code.

Software supply chain risks are escalating. Between 2020 and 2021, bad actors launched nearly 7,000 software supply chain attacks, representing an increase of more than 600%. Without identifying and managing security risks within the supply chain, you could be exposing your critical assets to attacks. Implementing a supply chain risk management strategy is essential to staying ahead of the potential threats and making the most of your software.

Everybody’s talking about securing the DevOps pipeline and shifting security left.. AppSec tools like SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), and others that address issues in proprietary software have become staples of the developer’s security toolbox.

Today, we announced our entrance into the Static Application Security Testing (SAST) market. It’s a significant development for WhiteSource, which has until now been solely focused on open source software security. In this post, I explain why we decided to make this move beyond open source into proprietary code security, and the value it will bring to developers, security teams, and their organizations.

In 2021, the WhiteSource Diffend automated malware detection platform detected and reported more than 1,200 malicious npm packages that were responsible for stealing credentials and crypto, as well as for running botnets and collecting host information from machines on which they were installed.

In the latter part of December 2021, WhiteSource Diffend detected the new release of a package called @maui-mf/app-auth. This package used a vector of attack that was similar to the server side request forgery (SSRF) attack against Capital One in 2019, in which a server was tricked into executing commands on behalf of a remote user, thereby enabling the user to treat the server as a proxy for requests and gain access to non-public endpoints.