9 posts tagged with "application-security"

Hello!

Today, I’d like to touch on open-source intelligence, or OSINT. According to Wikipedia, open-source intelligence is the collection and analysis of data gathered from open sources (covert sources and publicly available information) to produce actionable intelligence. As you can infer from the definition, OSINT is a vast topic, and the best way to understand such broad topics is through concrete, narrow-scoped practical examples. In this blog post, I’d like to share one of the approaches on how OSINT techniques can be applied to bug bounty hunting for products with publicly hosted code on GitHub, using the awesome open-source project Grafana as an example. Read on!

Hello!

In my previous post, I shared the update regarding the upcoming "Q3 2023 - Jul-Sep" milestone. While I briefly covered how I implemented the notifications subsystem in Secutils.dev, there are a few other important changes I've been working on for this milestone. One of these changes is related to the fact that I’m preparing to allow Secutils.dev users to inject custom JavaScript scripts into the web pages they track resources for (yay 🎉). As a result, I've spent some time hardening the Web Scraper environment's security and wanted to share what you should keep in mind if you’re building a service that needs to scrape arbitrary web pages.

Hello!

With just one month remaining in the "Q3 2023 - Jul-Sep" milestone (this is how I structure my roadmap), I wanted to provide a quick progress update. A significant deliverable for this milestone includes adding support for email notifications and other transactional emails.

Notifications, in general, and email notifications, specifically, are integral to any product that involves any monitoring or tracking activities. Secutils.dev already includes, and will continue to expand, features that require the ability to send notifications. Two notable examples include sending notifications for changes detected by the web page resources trackers and changes detected in the tracked content security policies (CSP).

Hello!

As you might have guessed, I spend a lot of time thinking about application security - almost every day, in fact. At my day job, I'm constantly pondering how to enhance Kibana's security in a scalable manner without overburdening my already hardworking team. Outside of work, I'm equally dedicated to making Secutils.dev even more valuable to fellow engineers looking for better security tools.

While I'd love to tell you there's a magic tool or a combination of tools that can make your application completely secure, I don't believe it's quite that simple - at least not yet. If you're working within tight budget constraints, resist the urge to spend it all on solutions like Veracode, Snyk, Secutils.dev, or any other security tool. Also, don't obsess over supply chain security and penetration testing just yet. Instead, focus your initial investment on something absolutely critical - educating your engineers about security. You'll reap the rewards, and so will your team. Only once you have a solid educational program or processes in place should you consider investing in additional security-oriented tools.

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.