Reasonable 🔐AppSec #21 - Five Security Articles, The Hamster 🐹 Wheel of Scan and Fix, and Podcast Corner

A review of application security happenings and industry news from Chris Romeo.

Hey there,

In this week’s issue of Reasonable Application Security:

  • Five security articles 📰 that are worth YOUR time

  • Featured focus: The Hamster 🐹 Wheel of Scan and Fix

  • Application Security Podcast 🎙️Corner

  • Where to find Chris? 🌎

Five Security Articles 📰 that Are Worth YOUR Time

  • Most articles you see are pro-Champion programs, but here’s one that goes in a different direction. Explore the limitations and misconceptions surrounding the role of "security champions" in organizations, emphasizing that while they play a crucial part in enhancing security, they should not be viewed as the sole solution to all security challenges. Do we have a new Champion curmudgeon on the loose? (more)

  • Silicon Valley has a unique approach to software engineers, valuing them as creative problem solvers and contributors to business growth, contrasting with traditional firms that see them as mere workers; it underscores autonomy, transparency, business metric exposure, efficient communication, and viewing tech as a profit driver. As reasonable AppSec people, we should grow our understanding of development folks. (more)

  • Speaking of learning more about developers, software engineers have various seniority levels, from entry to fellow, highlighting their responsibilities and the disparity between titles and actual capabilities while discussing salary implications and the distinction between engineering and management tracks. (more)

  • Yes, ChatGPT is coding away, but how good of a job is it doing? An experiment was performed where two developers, Ned and Dan, were tasked with implementing rate limiting for web applications and APIs;. At the same time, Ned used traditional development techniques. Dan utilized the ChatGPT Large Language Model, and the article shares their experiences, challenges, and insights gained from using both methods. (more)

  • To complete too much focus on AI and LLMs, let’s explore the methods and importance of monitoring and observing Large Language Models (LLMs), emphasizing continuous evaluation, tracking, and monitoring to ensure responsible AI practices and safeguard user experience and brand reputation. Monitor your robot overlords until you can no longer keep tabs on them. (more)

Featured focus: The Hamster 🐹 Wheel of Scan and Fix

Why are we so overly focused on scanning and fixing application security issues? We’ve created a whole cottage industry of tools that scan stuff to create a list of problems.

The primary challenge is dumping this list of problems on development teams and saying, “Fix them. Fix them all!”. Development teams then have 10,000 issues, of which most get junked over some time.

How did we get here? How did we, as an industry, end up in this scan and dump issues hamster wheel? If we want a culprit from the world of AppSec/SWSec, it’s Static Application Security Testing (SAST). SAST was the first AppSec tool, dating back to the late 1990s, with the introduction of SQLi vulns.

SAST set the model, but it wasn’t the original offender. If we go further back, network vulnerability tools like Nessus introduced the scan and fix pattern of security tooling. Scan a network, find open ports, identify likely vulns, and generate a list of issues via report. SAST was following the leader, and the leader was a destructive pattern.

But is there a better pattern? One that is more usable for developers. Does shift left get us away from the hamster wheel? It doesn’t. It just recommends starting the hamster wheel earlier.

We need a new pattern for tooling. Perhaps AI is the answer, where the tooling scans and introduces the PR/fix for you, relieving the backlog ignored issue problem. But even with AI, we’re still talking about scan and fix. It's just fancy robot fixing.

Is the RASP/IAST pattern the answer? If we use RASP in production as an example, RASP doesn’t scan/fix; it views&blocks/allows. What would it take to make the other AppSec tools follow this pattern? We’d have to embed SAST into the runtime of the application, where it scans the code as it’s used and blocks the request if there was a code-based flaw. I’ve already talked myself out of this option for many reasons (performance, strangeness of placement of the security control).

Now, I’m going down the road of something else that’s been tried: the just-in-time security in the developer IDE. If we could introduce the scanning function into the IDE in real time, we should be able to sound a buzzer and get the developer to fix the problem in real time so we get away from the stack of issues. The counter-argument to this is that the buzzer sounds break the developer’s flow and make them less productive. This still doesn’t feel like the answer to our industry’s woes.

I wish I had the answer to this one. Look for my post on LinkedIn and let me know how we can redesign our industry. It seems like a complicated problem, but is it?

Podcast 🎙️ Corner

I love making podcasts. In Podcast Corner, you get a single place to see what I’ve put out this week. Sometimes, they are my podcasts. Other times, they are podcasts that have caught my attention.

Where to find Chris? 🌎

🤔 Have questions, comments, or feedback? I'd love to hear from you!

🔥 Reasonable AppSec is brought to you by Kerr Ventures.

🤝 Want to partner with Reasonable AppSec? Reach out, and let’s chat.