We recently announced our beta release for PHP support in Snyk Code, which brought with it the ability to identify potential PHP security vulnerabilities at the code level. After a successful public beta program, PHP security support in Snyk Code is now GA. 🎉🎉🎉 PHP is a popular programming language that is used by developers all over the world. In this blog post, we will take a look at some of the features of Snyk Code and how it can be used with PHP.
The Log4Shell vulnerability took the Java community by surprise at the end of 2021, and many organizations are still mitigating its impact. To help development teams stay informed as the situation unfolds, Snyk has created and continues to update its Log4j vulnerability resource center.
At SnykCon 2021, there were a number of insightful talks from companies that were able to build successful AppSec programs. As the Lead Platform Architect at Lunar and a Cloud Native Computing Foundation (CNCF) ambassador, Kasper Nissen’s presentation was no exception. In this post, we’ll recap Nissen’s talk about how his security team at Lunar was able to shift security left while building a cloud native bank.
The Cambridge Dictionary defines a policy as: “a set of ideas or a plan of what to do in particular situations that has been agreed to officially by a group of people, a business organization, a government, or a political party.” And in the context of software development, your organization may have some rules about how a policy is built, configured, deployed, and used. Some examples of software policies include.
Snyk Code provides a new generation of static application security testing (SAST). It uses a unique process that uses machine learning to rapidly grow its knowledge base and a Snyk security engineer to assure the quality of the rules. As a result, the Snyk Code knowledge base grows exponentially and results in an industry-leading high accuracy. On top of that, Snyk Code provides real-time scanning so developers can use it right from their favorite IDE.
Traditionally, we start the new year with resolutions. We want to do more good things, like working, other things we try to eliminate. Considering the latter, my 2022 resolution is to stop accidentally exposing confidential information while I hack my application during demos on stage or similar. Yes, this new years resolution sounds very specific, and it has an excellent security horror story behind it…
URLs have forever changed the way we interact with computers. Conceptualized in 1992 and defined in 1994, the Uniform Resource Locator (URL) continues to be a critical component of the internet, allowing people to navigate the web via descriptive, human-understandable addresses. But with the need for human readability came the need for breaking them into machine-usable components; this is handled with URL parsers.
On January 8, 2022, the open source maintainer of the wildly popular npm package colors, published colors@1.4.1 and colors@1.4.44-liberty-2 in which they intentionally introduced an offending commit that adds an infinite loop to the source code. The infinite loop is triggered and executed immediately upon initialization of the package’s source code, and would result in a Denial of Service (DoS) to any Node.js server using it.
Earlier this week, the FTC issued a warning to companies regarding the Log4j vulnerability. Given the rampant exploitation of the recently discovered vulnerabilities in this ubiquitous open source logging package, it’s encouraging to see the agency take this rare step, beginning to form a firm stance on software supply chain security. Although this increased scrutiny from the FTC may at first seem daunting, violations can be remediated with the right practices.
