Hello!

This is the second part of my reflection sparked by the recent “2023 State of Open Source Security” report from Snyk. It got me thinking about the price we pay for false positives in software security. In my previous post, “The Cost of False Positives in Software Security, Part 1: Small Applications”, I talked about how true and false positives affect smaller applications like Secutils.dev. Now, I want to take the same idea and apply it to a much larger software that’s a big part of my daily work: Kibana.

Saying that Kibana is one of the biggest Node.js apps you can find on GitHub would be no exaggeration. Just a quick glance at its monthly GitHub activity tells you all you need to know about its sheer size and scope!

The code size, complexity, and the multitude of use cases it serves, combined with the numerous teams working on it, make Kibana an ideal case study for this post.

Hello!

The other day, I was reading the "2023 State of Open Source Security" report by Snyk. It’s a nice report to read if you're curious about the state of the modern application security landscape, but here’s the part that particularly resonated with me:

The constant rising tide of vulnerabilities continues to lead to security backlogs and decisions not to fix vulnerabilities. Part of the challenge here is false positives, which have increased alongside growing security processes and tooling automation. This is clear evidence that, while automation allows for much better coverage and detection, it can introduce data quality issues that are challenging for already stretched security teams to triage and accurately assess. In fact, false positives are reported at such a high volume that it is highly likely security teams are misclassifying some of these warnings. The sheer volume of CVEs that are ignored and left unfixed in applications (either by not applying patches or not versioning software) indicates that organizations are struggling to keep up with the demands of maintaining an airtight supply chain security posture. The widespread introduction of Al and automation injects additional uncertainty, making it harder to stay abreast, let alone get ahead, of supply chain security concerns.

False positives in security are something that really bothers me, as I happen to work on security for both large applications like Kibana, with hundreds of contributors, and smaller ones like Secutils.dev, where I'm the sole developer.

Hello!

As you might have learned from the "A Plan for the Q3 2023 Iteration" post, my focus for this iteration is on adding support for automatic scheduled resource checks for the "Web Scraping → Resources trackers" utility in Secutils.dev. This work is already in progress, and in this post, I'd like to share more details about how I'm designing the scheduler for Secutils.dev. If you're building a scheduler for your application, hopefully, you can learn a useful thing or two.

Hello!

In one of my previous posts, I mentioned that I wrapped up the "Q2 2023 Apr-Jun" iteration and moved on to the next one: "Q3 2023 Jul-Sep". In this post, I want to briefly cover what I'm going to work on during this iteration. I'll highlight three main areas: improvements to the certificate templates, scheduled automatic web page resources checks, and shareable content.

Hello!

In my previous post, I briefly touched on the latest 1.0.0-alpha.2 release of Secutils.dev. While the "Resources tracker" was the central part of this release, I want to highlight one tiny fix that makes a huge difference in user experience but can also be quite risky if not done right: “Recover original URL after sign-in”.

Hello!

This weekend, I finally wrapped up the "Q2 2023 – Apr-Jun" iteration and cut a new 1.0.0-alpha.2 release of Secutils.dev. Admittedly, this release was delayed "a bit" (well, almost 3 weeks delay, that happens) since I needed slightly more time to prepare the "Resources tracker" functionality for the general public. I tried to explain why it wasn't a trivial task in the "Detecting changes in JavaScript and CSS isn't an easy task" series of posts (part 1, part 2, part 3). Check them out!

If you want to learn more about the "Resources tracker" functionality, I encourage you to start from this guide. For your convenience, I'm also attaching a short video clip here demonstrating how it works using a "fake" HTML page backed by the "Responders" feature. For the rest of the changes included in this release, please refer to the full changelog at secutils@v1.0.0-alpha.2.