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.

I conducted research based upon existing Python vulnerabilities and identified a common software pattern between them. By utilizing the power of our in-house static analysis engine, which also drives Snyk Code, our static application security testing (SAST) product, I was able to create custom rules and search across a large dataset of open source code, to identify other projects using the same pattern. This led to the discovery of a stored command injection vulnerability in Celery.

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.

As applications become more complex, so does the task of securing them. While the source code making up applications consists of proprietary code, a great deal of it is also third-party, open source code. Development and security teams looking to release secure code while also maintaining a rapid pace of development, need to therefore combine static application security testing (SAST) and software composition analysis (SCA) as part of a comprehensive software security strategy.

The Payment Card Industry Data Security Standard, also known as PCI DSS is a thorough process that reviews a company’s systems and policies for handling and storage of sensitive consumer cardholder data.