The Consortium for Information and Software Quality estimates that the cost of poor software quality in the United States reached $2.41 trillion in 2022. That’s nearly 10% of the current GDP within the US. As we will show, it makes sense that the cost of poor software quality is so high. It’s also completely avoidable, and software flaws must be avoided with the world’s increased dependency on software.
There will always be a natural tension between cybersecurity teams and developers. After all, it's the developer's role to "develop." They want and are paid to create and ship new applications and features that help move the organization forward. It's the role of security, however, to make sure bad things don't happen when new software is deployed, such as suffering from a data breach or the loss of availability of business services due to vulnerable software.
API security should not be viewed as a luxury, but rather as a requirement. As APIs have become indispensable for modern applications and services in our increasingly interconnected digital landscape, they need safeguards shielding them against the numerous threats and malicious actors of the digital world.
Who owns the responsibility of the software development lifecycle (SDLC) in your business? It’s easy to assume, through a traditional lens, that the CEO and/or Board of Directors might ultimately be responsible for what takes place throughout the SDLC
For some time now, public companies in the United States have been on notice that the Securities and Exchange Commission (SEC) is tightening down on the reporting of security incidents. Now that the compliance deadlines are here, it seems a bit more real. As a complement to my recent webinar "SEC Cybersecurity Ruling: Application security + incident response" this piece serves as a recap and a checklist on what businesses – both public and private – need to be focusing on now that the SEC disclosure rules are here.
Back in 2021, Google launched, alongside other organisations, a new security baseline for products known as the Minimum Viable Secure Product. Now, 2 years later, they've released an update to that standard.
The Security Headers grading criteria is something that doesn't change often, but when it does, there's a good reason behind the change. In this blog, I will outline the new grading criteria and the reasons why we've made the change.
In the world of cyber security, knowledge is power, and Security Headers has been a trusted ally for web developers around the world for years. For the first time ever, thanks to the support of our partnership with Probely, we’re going to delve into the treasure trove of historic scan data and explore the insights it can provide.
Let’s take a look at my big takeaways from this year’s event and what I’ve learned. Beyond great briefings and learning from those around me, events like Black Hat are also a great opportunity to make and develop connections. We had countless members of the security community stop by our booth for a selfie and some swag, we attended countless social events and even hosted our own!
