The SolarWinds attack in late 2020 exposed the data of more than 18,000 businesses and governmental departments – many of which are gatekeepers for the country’s most vital infrastructure. While attacks against the software supply chain aren’t new, they are increasing exponentially.
As organizations look for solutions that enable them to create a software bill of materials (SBOM) to ensure they’re meeting new governmental mandates for protecting the software supply chain, it’s important to understand the difference between solutions based on reporting vs. remediation. The primary focus of any SBOM solution should be on open source code. The use of open source continues to expand exponentially. Open source components comprise 60%-80% of today’s applications.
According to the National Vulnerability Database (NVD), the number of new security vulnerabilities increases steadily over the past few years. Image source: NVD The consistent rise in the number of security vulnerabilities along with headline-catching exploits like the SolarWind supply chain attack earlier this year has organizations doubling down on vulnerability management programs to ensure that they are not exposed to malicious attacks.
Risk management of code is an important and often overlooked development function that you need to pay attention to. You may think that this is not a developer’s problem, however developers should not write code that unduly adds to technical debt, hence the need to manage risk. The primary motivation for risk management is to prevent error or failure. Do not seek to eliminate failure, seek to minimise it, to manage the risk of failure.
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.
