A few hours ago, an npm package with more than 7 million weekly downloads was compromised. It appears an ATO (account takeover) occurred in which the author’s account was hijacked either due to a password leakage or a brute force attempt (GitHub discussion).
There’s a shift in the world of DevOps. It is no longer enough to create applications and just launch them into the cloud. In a world where entire businesses can exist online, securing your digital assets is as important as creating them. This is where DevSecOps comes in. It is the natural progression of DevOps — with security being a focus as much as the process of creating and launching applications.
DevOps has transformed the software development industry. The merging of development (Dev) and operations (Ops) teams has largely contributed to quick and effective software releases. The continuous evolution of the application security threat landscape requires organizations to integrate security into the DevOps culture. Thus, DevSecOps has emerged to extend the capabilities of DevOps and enable enterprises to release secure software faster.
Keeping up with today’s rapidly evolving threat landscape is an ongoing battle for software development organizations, as many struggle to keep their assets and customers secure while keeping up with the competitive pace of software delivery.
Software supply chain attacks have been on the rise lately. With the current pervasiveness of third-party and open source libraries, which presumably developers cannot control as strongly as the code they create, vulnerabilities in these software dependencies are causing serious security risks to applications. Supply chain attacks abuse the inherent trust that users have with a software provider.
The Open Web Application Security Project (OWASP), founded by Mark Curphey, first released the OWASP Top 10 Web Application Security Risks in 2003. The Top 10 is the closest the development community has to a set of commandments on how to build secure applications. This list represents the most critical risks to software security today and is recognized by developers as the first step toward creating more secure code.
When it comes to PHP, composer is without discussion, THE package manager. It’s fast, easy to use, actively maintained and very secure — or so most thought. On April 21, 2021, a command injection vulnerability was reported, which shook the PHP community. Fortunately it didn’t have a very big impact, but it could have. The problem with the vulnerability is that it affected the very heart of the Composer supply chain: Packagist servers.
Banking has changed. In the past, financial institutions outsourced their technology. They had large consulting firms creating, managing, and maintaining their back-end systems. Although banks would have knowledge of the systems in place, they wouldn’t be running them on a day-to-day basis. That was the consultants’ responsibility. Recent years have seen a significant shift in the financial sector.
Considering our reliance on open source and third party components, it’s nearly impossible to estimate how many open source libraries we’re using, especially with dependency management tools that pull in third party dependencies automatically. Adding to the challenge of keeping track of the open source components that make up our codebase, is the tangled web of transitive dependencies.
The Forrester Wave™ Software Composition Analysis, Q3 2021 report states that open source components made up 75% of all code bases in 2020. This is more than double the 36% in 2015. As organizations increasingly rely on external components to quickly add functionality to their own proprietary solutions, they take on greater risk, especially considering these open source components may contain unmitigated vulnerabilities or violate organizations’ compliance policies.
