Panel recap: Breaking Bad Security Habits with Corey Quinn

On December 8th, Clinton Herget and Simon Maple, Field CTOs at Snyk, had the opportunity to chat with Corey Quinn, Chief Cloud Economist at The Duckbill Group, podcast host, curator of "Last Week in AWS”, and snarky Twitter personality.

Their conversation took a lot of fun turns, from ranting about the hour-long line to get coffee at AWS re:Invent, to Corey proclaiming that “SBOMs are a fantasy” (there’s more context to that… keep reading). We’ll cover a few of the biggest highlights in this blog, but if you want to hear every Corey Quinn-ism from this conversation, watch the whole panel here.

AWS re:Invent 2022 takeaways

Since AWS re:Invent 2022 just ended, Corey and Clinton took a few minutes to cover their biggest takeaways. Corey emphasized that it’s important to prioritize meeting people over attending sessions.There are only so many hours in a day at AWS re:Invent, and Corey enjoys using them to meet AWS folks instead of sitting in sessions. After all, sessions are available on-demand after the conference, but getting to chat with AWS experts in person is not.

Clinton was excited about the announced details of an Open Cybersecurity Schema Framework(OCSF) commitment from Amazon Web Services. By standardizing a security framework, AWS is setting the precedence of an interoperable and machine-readable language for describing application security. Clinton foresees this as the first step towards better industry-wide conversation around shared risk.

Reflecting back: AWS security horrors of 2022

Corey Quinn and Clinton Herget also looked back at 2022, reflecting on a few AWS security “horrors” that definitely need to be addressed in the new year. The biggest ones included:

The disconnect between development and production environments

According to Clinton, one of the most significant issues in today’s software development is the gap between development and production environments. Because everything in the cloud is code, any type of remediation for security risks needs to happen within the code. He says, “As an operator, I get a big flashing red scary alert saying ‘you have Log4J in a pod on an EKS cluster; you need to fix it.’ Then what? There is no machine-readable and automated way to understand what file and what Git repo actually needs to be changed as a result of that notification.”

Too much implicit trust in the software supply chain

Additionally, software development teams went wrong in 2022 by putting too much trust in the components within their software supply chain. Rather than assuming that every piece of open source software and its dependencies are secure, teams need to verify that their third-party components are actually safe to use.

SBOMs that don’t go deep enough

Corey also brought up that today’s software bill of materials (SBOMs) aren’t doing enough. In his opinion, they don’t do justice to the interconnected nature of a modern-day app. You can follow transitive dependencies down a rabbit hole of a “dependency of a dependency of a dependency,” and so on, but never fully understand the level of third-party risk within your app.

Solutions to today’s security challenges

Clinton and Corey also covered how companies should think about and respond to these “2022 horrors” as the new year approaches. They discussed:

Supplementing SBOMs with other best practices

So, what’s the solution to improving today’s SBOM practices? Corey Quinn jokingly said that “actually fixing this requires patching human beings.”

In other words, writing down the contents of your entire software supply chain won’t solve security issues; shifting organizational culture and empowering human beings to solve security problems does. A big part of this involves reducing security alerts — minimizing noise so your team can triage what really matters within your SBOM.

Clinton also added that organizations shouldn’t be so ashamed of their open source usage. When they understand that using open source is acceptable — and not a potential risk to their business success — organizations can become much more transparent about which shared components are being used and where.

Deeply understanding your organization’s existing processes

How do your IaC, cloud, and source code relate to each other? How does your security team work with your developers, and vice versa? What contexts do each of these individuals look at on a daily basis? Clinton and Corey emphasized the importance of taking a step back and answering these questions. It makes all the difference in how each business unit sees and addresses risk.

Corey also mentioned that he’s “very hesitant to wind up giving advice beyond ‘understand the context you're operating within and make decisions that make sense for you.’” This is why organizations need to ask deeper questions and uncover security best practices that work for them.

Working with — not against — the context of your development team

Security is often a reactive discipline. Corey mentioned that while necessary, security efforts don’t drive your business forward in any tangible way. Because of this, they often get put on the back burner. Assuming that most departments feel this way about security, teams must make security practices as frictionless as possible.

The SDLC needs to be secured with as little manual work as possible. Especially when it comes to empowering developers with security best practices, it’s all about connecting to the context of the developer and understanding what they work with daily.

New year, new AWS security opportunities

This is just scratching the surface of what Corey and Clinton discussed. They brought up a plethora of AWS security opportunities for 2023, from a deeper focus on developer-first security to increased transparency of software supply chains and much more.

Be sure to check out their entire conversation here. Also, learn more about how Snyk’s developer security platform can help you grow your security program in 2023.