Reasonable 🔐AppSec #52 - Secure by Design Pledge, Five Security Articles, and Podcast Corner

Hey there,

In this week’s issue, please enjoy the following:

• Five security articles 📰 that are worth YOUR time

• Featured focus: Secure by Design Pledge

• Application Security Podcast 🎙️Corner

• Where to find Chris? 🌎

Five Security Articles 📰 that Are Worth YOUR Time

1. Comparison and Evaluation on Static Application Security Testing (SAST) Tools for Java — Daniel Cuthbert offers commentary on a paper that examines the performance of various SAST tools by comparing their ability to detect synthetic and real-world vulnerabilities in Java applications. The paper discusses the challenges these tools face in accurately identifying complex real-world vulnerabilities, highlighting the disparity between vendor claims and actual tool effectiveness in diverse testing environments. [SAST continues to be a foundational tool for AppSec teams, but how good is it? This analysis and paper provide answers.]

2. Capabilities & Limitations of AI in Application Security — A critical discussion of the capabilities and limitations of AI in application security, emphasizing AI's role in augmenting but not replacing human expertise in threat modeling and security process enhancement. The article highlights the importance of human oversight in design and decision-making processes, where AI is utilized to improve efficiency but cannot independently architect secure solutions. [OK, I’ll admit it. This was one of mine. I wrote this to share my take on the fundamental value proposition of AI in the short term for AppSec.]

3. Log4J Still Among Top Exploited Vulnerabilities, Cato Finds – Three years post-discovery, the Log4J vulnerability remains one of the top exploits, with Cato Networks reporting it constituted a significant portion of both inbound and outbound vulnerability exploitations in early 2024. Meanwhile, an older vulnerability in PHPUnit is also heavily exploited, showcasing the ongoing challenge of addressing unpatched systems. [Why can’t we have nice things? Because we can’t patch any vulns to the point where the vuln goes extinct.]

4. Vulnerability in R Programming Language Could Fuel Supply Chain Attacks — A newly identified vulnerability in the R programming language, tracked as CVE-2024-27322, could be exploited to execute arbitrary code through malicious RDS files, posing a significant risk for supply chain attacks. This vulnerability in R's serialization and deserialization process affects many industries that utilize R for statistical computing and machine learning and could compromise entire systems if exploited. [A few years ago, I built a secure coding course for Data Scientists and took a close look at R. You should be afraid, very afraid, of the lack of secure coding knowledge and expertise within the world of data science. They have all the data and little idea of how to protect it.]

5. Hacking AI Bias while Hacking Human Bias  — The U.S. Department of Defense launched an AI bias bounty program designed to identify and mitigate biases in AI systems by engaging security researchers in challenges. This initiative aims to enhance the fairness and accuracy of AI by addressing the biases inherent in their training datasets. [Bias should be entirely controlled by the training data with our current generation of LLMs. GIGO — garbage in, garbage out.]

Featured focus: Secure by Design Pledge

Last week at RSA, CISA sponsored a signing ceremony for the “Secure by Design Pledge.” I wish I was more excited about it. I’m a proponent of secure and private by design/default—so much so that I dedicated my talk last week at RSA to the topic.

My challenge with this “pledge” is that it has no teeth/bite. It’s a voluntary pledge with no accountability. We have to do something to move the industry forward, but I don’t see how this will do much.

Most companies that signed the pledge are large enterprises that have spent the last one to two decades building their software security programs. They had their act together before the pledge, and the pledge doesn’t require them to do anything differently.

The pledge contains some excellent requirements until you start to unpack what it says. For example, “GOAL: Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.”

Demonstrating actions could mean almost anything. You could host a lunch and learn to talk about a vuln class and call that demonstrating action. This requirement is too easy to meet and doesn’t take a strong enough stance.

The idea is solid—let’s focus on a class of vulns and try to squash them. Heck, we should do that as an industry. It’s time to put SQLi behind us—in the rearview mirror.

How about a requirement that says you agree not to ship any more code containing SQLi and to donate $10K to charity for each SQLi found in your production code? I don’t see any company’s legal team signing up for this.

I wish they had made this thing stronger, with a real chance of making a difference. For now, it’s lip service amongst companies already taking software security seriously.

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.

• Application Security Podcast

  • Devin Rudnicki -- Expanding AppSec (Audio only; YouTube)

    • Devon Rudnicki, the Chief Information Security Officer at Fitch Group, shares her journey of developing an application security program from scratch and advancing to the CISO role.

    • She emphasizes the importance of collaboration, understanding the organization's business, and using metrics to drive positive change in the security program.

• Security Table

  • 12 Factors of Threat Modeling (Audio only; YouTube)

    • Chris, Matt, and Izar share their thoughts on an article from Carnegie Mellon University’s Software Engineering Institute. The list from the article covers various threat modeling methodologies such as STRIDE, PASTA, LinDoN, and OCTAVE methodology for risk management.

    • They emphasize the importance of critical thinking in the field, provide insights into each method's strengths, applications, and limitations, and highlight the significance of annotated threat models for application security.

• Threat Modeling Podcast

  • Nandita Rao Narla -- Privacy Threat Modeling Wins, Losses, and Tools (Audio only)

    • Nandita Rao Narla outlines that privacy threat modeling often fails due to high costs, developmental friction, and compliance focus, recommending strategies like leveraging existing resources and simplifying methods for better adoption.

    • She discusses the limited use of specialized tools in privacy threat modeling, typically only data mapping and asset discovery.

    • She envisions integrating privacy with security threat modeling for enhanced organizational strategy in the future.

Pictures are Fun

Where to find Chris? 🌎

• Top Trends & Takeaways from RSAC 2024 (Webinar), May 22, 2024

  • Time: 9 am (PT) / 10 am (MT) / 11 am (CT) / 12 (ET)

  • Register here.

• InfoSec World, Sept 23-25, 2024

  • The Modern Application Security Rocket Ship — Time/date TBD

  • The Paradox of Secure and Private By Design — Time/date TBD

  • Workshop: Threat Modeling Championship: Breaker vs. Builder — Time/date TBD

• OWASP Global San Francisco, Sept 26-28, 2024

  • I’ll be hanging around the Devici booth.

🤔 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.