How 2023 Changed Application Security and What’s to Come in 2024 – Karl Triebes – ASW #263
Full Audio
View Show IndexSegments
1. How 2023 Changed Application Security and What’s to Come in 2024 – Karl Triebes – ASW #263
In the rapidly evolving landscape of application security, 2023 brought significant changes with the rise of generative AI tools and an increase in automated threats. In this discussion, Karl Triebes takes a deep dive into the major trends of the past year, examining their impact on the industry and shedding light on what security professionals can anticipate moving forward into 2024.
This segment is sponsored by Imperva. Visit https://securityweekly.com/imperva to learn more about them!
Sponsored By
Announcements
We're always looking for great guests for all of the Security Weekly shows! Submit your suggestions by visiting https://securityweekly.com/guests and completing the form!
Guest
For over three decades, Karl Triebes has helped conceive and build products, services, and businesses for networking, application software, storage, and cloud. At Imperva, he leads product management for the Application Security business unit, driving product innovation for customers. Prior, he was Executive Vice President of Product Development and CTO at F5. Triebes has also held senior leadership positions with Amazon Web Services, Foundry Networks, and Alcatel.
Hosts
2. Fuzzing Strategies, Responding to CISA’s Open Source Security RFI, 35 Year Old Worm – ASW #263
CNCF's releases a handbook on fuzzing, OpenSSF and OWASP respond to CISA's Open Source Software Security RFI, 14 years of Go, lessons for today from an internet worm from 35 years ago, and more!
Announcements
Dive deeper into the world of cybersecurity with Security Weekly on Instagram! Follow us @SecWeekly to find exclusive clips, hilarious memes, behind-the-scenes sneak peeks, and more! Stay connected, stay informed, and join our growing community!
Hosts
- 1. CNCF Fuzzing updates 2023
This article collects some recent reports on fuzzing efforts conducted by the CNCF against several of their projects. It also introduces a fuzzing handbook that looks useful if you want to better understand the benefits of fuzzing and some of the basics in setting up an environment for your own projects.
- 2. OpenSSF Responds to US Federal Government RFI on Open Source Software Security
I like the areas this covers, especially where to focus memory-safe improvements. It includes a recommendation to "encourage MFA" for repos and package managers. I'd love to see this as a requirement, but as the response also highlights, open source software has global participation. So, perhaps this needs to be a requirement driven by more social pressure than any regulations.
- 3. OWASP’s response to the ONCD RFI on Open Source Security and Prioritization
Unsurprisingly, there's a big push for ASVS and SAMM as projects to help improve the security of open source software. (I think ASVS needs a lot of work to make it more useful for secure design and reframing to make it less of a checklist mentality.) Like the OpenSSF, OWASP points out the need for developer eduction, which they highlight as one of their strengths.
- 4. HISTORY: Fourteen Years of Go – The Go Programming Language
Go has been bringing security tooling into its dev environment, from fuzzing to vulncheck to reproducible builds. It's no surprise that a lot of that evolution follows larger efforts from Google like SLSA, but it's a benefit to the community.
- 5. HISTORY: Reflecting on the Internet Worm at 35 – CERIAS – Purdue University
“In 1988, fewer than 100,000 machines were likely connected to the Internet…”
The lessons here aren't about a quaint era when the total number of systems wasn't equivalent to a budget item for most Fortune 100 companies. Long-lasting access, privilege separation, and type safety (and memory safety) remain technical challenges today. The article also discusses more social aspects of appsec, such as transparency and information sharing, as well as "the propriety of hacking into other people's systems" that this worm brought to discussions -- those concepts aren't far removed from the "we take security seriously" breach disclosures and bug bounty programs of today.
- 6. TOOL: ZAP – Getting Further
ZAP is kicking off a new series of advanced guides for the proxy. Check it out, provide feedback, suggest new guides, and help out where you can!
- 1. 117 vulnerabilities in Microsoft 365 apps via SketchUp library
Zscaler's ThreatLabz has a really good writeup about how they reverse-engineered O365's new support for Sketchup, then fuzzed the support library and found a bunch of issues. While this is a fairly meaty piece, they do a good job of stepping through what they did.
Apparently this is only part one. I'll keep an eye out for part two...
- 2. Using one LLM to jailbreak another
An interesting paper is coming out that describes training an LLM to social engineer another LLM in a black-box style attack.
While I suspect this is similar to ML models that have been used in appsec tools for a while, the ease with which we can now train LLMs leads me to wonder if this could help teams roll their own custom threat LLMs for internal use...
- 3. Rust may be memory safe, doesn’t prevent path traversal in sudo-rs
There was a vulnerability in sudo-rs - the rewrite of sudo to rust to ensure better security. If a UNIX username contained a pattern of periods and slashes, a user can flush the session record file with "sudo -K" - but the username is concatinated with a path to determine the session file, so this could be used to zero out other files on the system.
- 4. Are javascript pros saying “goodbye” to Typescript?
This is a Medium piece, so take with appropriate grains of salt. That said - a few arguments are made for why some projects are moving away from TypeScript. Compile time and added complexity are the two main arguments. One idea is to use JSDoc to document types being used, without the overhead of TypeScript. The thing is, then you need to compile the JSDoc, so I don't fully see the advantage here.
Maybe just work on improving TypeScript compile times?
At the least, this is something worth thinking about...
