Reasonable 🔐AppSec #32 - Five Security Articles, The OpenSSF Secure Software Dev Guiding Principles — Do they require you to do anything of value?, and Podcast Corner

Hey there,

In this week’s issue of Reasonable Application Security:

• Five security articles 📰 that are worth YOUR time

• Featured focus: The OpenSSF Secure Software Dev Guiding Principles — Do they require you to do anything of value?

• Application Security Podcast 🎙️Corner

• Where to find Chris? 🌎

Note, this is the second to last Reasonable AppSec for 2023. After next week, we’ll take a two-week break for the holidays.

Five Security Articles 📰 that Are Worth YOUR Time

1. “Secure by Design Alert: How Software Manufacturers Can Shield Web Management Interfaces From Malicious Cyber Activity” — This CISA guidance urges software manufacturers to proactively prevent the exploitation of vulnerabilities in web management interfaces by designing and developing their products using Secure by Design principles, which include taking ownership of customer security outcomes and embracing radical transparency and accountability​.

2. “Rethinking the Scan and Fix Hamster Wheel: A New Paradigm for Application Security” — There are challenges to the current application security approach, which focuses on scanning and fixing vulnerabilities using tools like SAST and DAST. It criticizes this approach as reactive and inefficient, leading to a hamster wheel effect. The author advocates for a new paradigm that balances security and efficiency, integrating security tools seamlessly into developer workflows without compromising productivity.

3. “Consumer Software Security Assessment: Should We Follow NHTSA's Lead?” — Should we establish a consumer software security organization, similar to the NHTSA for vehicles, to ensure software meets basic security standards and is user-friendly? It highlights the complexity of modern software and the importance of default security settings. It suggests a safety rating system for software, akin to vehicle safety ratings, to help consumers make informed decisions about their digital security and privacy.

4. “Almost all developers are using AI despite security concerns, survey suggests” — 96% of developers use AI tools, often bypassing security policies, despite awareness that these tools frequently generate insecure code; it emphasizes the need for increased security measures and awareness to mitigate the risks associated with relying on AI for coding.

5. “U.S, U.K. And 16 Other Nations Agree On AI Security Guidelines” — An agreement was signed by 18 countries, led by the UK and the US, on AI safety, focusing on secure by design principles for AI system development, aiming to integrate cybersecurity into the entire development process of AI systems.

Featured focus: The OpenSSF Secure Software Dev Guiding Principles — Do they require you to do anything of value?

As 2023 comes to a close, I’ve been thinking that perhaps I’ve been too pessimistic in questioning many things I see coming across my desk or LinkedIn. Then I read the OpenSSF Secure Software Development Guiding Principles. I found myself struggling to understand what compliance with these principles unlocks. Let’s walk through them and discuss them.

1. To employ development practices that are in conformance with modern, industry-accepted secure development methods.

Great start, but what are industry-accepted secure dev methods? Could we please call these things out and perhaps adjust the minimum bar a year from now? Do you mean SAST? SCA? Gasp, DAST? Or SDL. Or secure by design/default. What do you mean? Keeping things so high level removes any real meaning from the statement.

2. To learn and apply secure software design principles (such as least privilege).

Once again, least privilege is a great design principle. Could we call out the other ones you have in mind versus leaving us to discuss and debate what the list of principles entails?

3. To learn the most common kinds of vulnerabilities and to take steps to make them unlikely or limit their impact.

Ahh, yes. I see now. We should figure out what our top vulns are and then make them go away. It all sounds so simple….

At this point, I can’t continue through the list and tear them apart. I decided to update their list and add my own words to them. Here we go!

1. Employ a set of secure development lifecycle practices, including modern, industry-accepted, secure development methods like threat modeling, source code review for security and privacy, code scanning (SAST, SCA), and runtime protection (RASP).

2. To learn and apply secure software design principles, including:

   • Minimise attack surface area

   • Establish secure defaults

   • The principle of Least privilege

   • The principle of Defence in depth

   • Fail securely

   • Don’t trust services

   • Separation of duties

   • Avoid security by obscurity

   • Keep security simple

   • Fix security issues correctly

3. To learn the most common vulnerabilities plaguing the things we build and take steps to reduce our vulnerability load over time. [Reducing vuln load is the only thing we can do successfully; we can state that we’ll remove vulnerabilities, but it won’t happen.]

4. To check for and address known and potential critical vulnerabilities before releasing software, then monitor for vulnerabilities throughout the product's supported life. [This one was good — it didn’t need much.]

5. To harden and secure our software development infrastructure against compromise or infiltration against the same principles, practices, and expectations set for the software developed and built from them. [This one as well — only slight wording tweaks.]

6. [This needed a rewrite because it’s not practical. Open source is open source, and I usually need what the package provides, and there are no alternatives.] To utilize a collection of criteria to choose software from suppliers and developers that publicly report security health metrics and adopt controls to prevent tampering of software packages and that actively address known/discovered malicious software. Choosing the best available package is the goal, but it is not always the answer.

7. To provide software supply chain understandability to consumers of our software consistent with evolving industry standards, practices, and tooling. To consume the artifacts of the software supply chain artifacts and take action upon the information I am provided. [SBOM must be active to have any value.]

8. To manage responsible vulnerability disclosure programs that include upstream dependencies and have publicly documented vulnerability reporting and remediation policies. [This one is fine.]

9. To publish security advisories consistent with evolving industry best practices. [This one is fine.]

10. To actively collaborate with and participate in industry and regulatory initiatives related to securing the software supply chain and to evangelize the adoption of the Secure Software Development Guiding Principles among our industry peers. I struck this one ultimately. You don’t have to do this to develop secure software.

Once again, let’s think about the things we prescribe for our industry, and don’t be afraid to push back when something doesn't make sense!

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

  • Arshan Dabirsiaghi -- Security Startups, AI Influencing AppSec, and Pixee/Codemodder.io (Audio only; YouTube)

    • Arshan Dabirsiaghi discusses the challenges in app security, the dynamic nature of startups, and the future role of AI in application security while also exploring his team's work on Codemodder.io, an open-source tool aimed at improving security practices in development.

• Security Table (we took a break this past week, but here is an oldie but goodie)

  • AppSec vs. ProdSec (Audio only; YouTube)

    • We engage in a lively debate attempting to demystify and differentiate Application Security and Product Security. We discuss the role of hardware, supply chain challenges, and the overlap between the two concepts.

• Threat Modeling Podcast

  • A new episode, "Privacy and Threat Modeling in Practice,” is coming soon. I promise it is. I’m planning to get back to the Threat Modeling Podcast in December.

Where to find Chris? 🌎

• The rest of 2023 — relaxing in Raleigh, NC, building new features supporting the Devici beta, and preparing for a busy 2024.

• North Carolina Cybersecurity Symposium, February 22-23, 2024

• BSides SF, May 4-5, 2024

• RSA, San Francisco, May 6 - 9, 2024

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