When you think of Seattle, you might immediately think of Starbucks, the Space Needle. or maybe even Fraiser. You might not think about hills. The Emerald City is built on seven hills, though 'hill' is an understatement. This elevation helped early settlers stay dry and safe from the waves of Puget Sound while giving them a firm foundation for their houses. Like our brave ancestors, hundreds of security professionals gathered in Seattle to build a firm foundation and elevate their knowledge around securing applications at CloudNativeSecurityCon 2024!

This was the second-ever CloudNativeSecurityCon held at the brand-new Summit addition to the Seatle Convention Center. Dozens of speakers shared their knowledge and experience building cloud-native applications and stories about challenges they have faced along the way. There were workshops, a capture-the-flag experience, and, of course, the hallway track, where the community really connects. Throughout it all, there was a real sense of urgency that we must work together to face the rapidly evolving threats we all face around authentication and authorization without using long-lived credentials. 

It would be impossible to capture the true spirit and all the learnings of this event. Here are just a few highlights. 

Better security can mean less development work

In her opening keynote, "Demystifying Secure Application Communication with Zero Trust: Identity, Integrity, Confidentiality," Lin Sun, Head of Open Source at solo.io, demonstrated the toil a developer needs to go through when manually implementing Mutual Transport Layer Security (mTLS) and then shared a better approach. When thinking through how our machine identities communicate, it all boils down to being about to prove they are allowed to connect. We can do this in a number of ways, but everyone agrees that long-lived credentials are a terrible approach. 

Instead of just discussing the theory of securing an application, she opened a code editor and began building an app and the tedious steps of implementing mTLS. There is a lot to keep track of when implementing such a solution, accounting for it in the client and the server, requiring a lot of manual configuration. Then, with a lot less fuss, she implemented SPIFFE with Istio, without sidecars. This is a way to give every entity a unique ID, allowing services to request short-lived, just-in-time certificates to enable communication. It was startling to see how fast she could achieve secure communication with just a few minor app changes, making for a much more attractive dev experience.

What's so hard about logging in? 

In their presentation "Learn to Navigate the Perils and Pitfalls of Multi-Tenant Identity Infrastructure," Zitadel's Co-Founders Fabienne Bühler & Livio Spring asked an alarmingly simple question: How hard is it to secure a login process. After all, there are only two fields: username and password. The reality is that underneath this simple interface, there is a whole hidden iceberg of challenges and competing technologies that all need to be considered, making this one of the more complex security challenges we face.

What kind of MFA should you use? Will you allow OpenID Connect? What about passwordless approaches like FIDO2-compliant solutions or biometrics? That is a lot to consider for a single user on a single app. Now multiply that set of decisions by all the types of users, such as internal staff, admins, end users, etc. Again, multiply this complexity across all your applications…it is easy to see this is a seriously large and complex concern. 

While Fabienne and Livio did not offer a silver bullet, they did lay out a simple framework for evaluating solutions. In their opinion, solving the multitenancy user authentication issue came down to a question of "Shared" vs. "Dedicated" system approaches. Each approach involves a trade-off of costs, management complexity, performance, and isolation. Ultimately how you secure your multi-tenant applications is going to depend on the budgets and organizational goals unique to you.

Documentation quality as a leading indicator for revenue and customer satisfaction

You might not have documentation on your list of ways to track your organization's productivity, but it likely should be on there. In her data-filled presentation "Amplifying Impact: Documentation and Supply Chain Security,"  Michelle Irvine, Technical Writer at Google Cloud and contributor to the DORA project, showed that this is an important metric to consider. Even though there is not much immediate feedback from documentation, especially internal documentation, teams that get this aspect right have less burnout and are much more productive. 

Using the research methodologies from the DORA program, Michelle cited eight attributes by which they evaluated documentation:

• Reliable (Functional)
• Clear
• Findable
• Comprehensive
• Organized
• Up-to-date
• Accurate
• Relevant

According to DORA research, the evidence is clear: security drives organizational performance and lower burnout across teams. In terms of security alone, the teams with the best document quality were 451% better than average at supply chain security. While building and maintaining exceptional documentation takes time, the value of undertaking such an effort is clear. Michelle urged us to focus on document quality over quantity, as endlessly sifting through too many docs is also a problem to avoid.

A full plate of security lessons

In his food-themed session, "A Mouthful of Mayhem: Taste Test and Gut Response to SLSA, GUAC, and Supply Chain’s Plat Du Jour," Shane Lawrence, Sr Staff Security Developer at Shopify walked us through what some of the latest industry terms mean with some dining analogies. He quoted computing science legend Ken Thompson in order to sum up the problem set: "You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)" He said that in 1983; the problem has only gotten worse since, with over 245,000 malicious packages discovered in 2023 alone. 

Just as we want to read the list of ingredients for our food, the Software Bill of Materials (SBOM) gives us the list of components that make up our applications. Supply-chain Levels for Software Artifacts (SLSA) verifies that the proper instructions were followed to create our applications, similar to how a health department certifies a restaurant is following the right policies when making our food.

CVEs are like warnings from the FDA for food recalls and public health warnings. He argued that SBOMs should not include vulnerabilities, the same way ingredient lists don't need to warn you about E. Coli outbreaks. Finally, the project Graph for Understanding Artifact Composition (GUAC) is a way to visualize the data around SLSA and SBOMs in a more digestible way, helping surface what really matters to your critical systems in a queriable framework.   

Building the future of Cloud Native Security together

One of the main things that stood out at CloudNativeSecurityCon this year was that the future of security is all of our responsibility, no matter your role. Your author was able to give a talk, one of many at this event, about scaling security through security champion programs. The trend is becoming clear: we can't relegate security to another department late in the process. We must shift to having pervasive security, shifted left, down, right, and all throughout our organizations.

This spirit of cooperation in solving security issues for all is present not just in internal teams but across the wider security community. It really stands out in the open source space in projects like OpenSSF and the Cloud Native Computing Foundation. This is evidenced by the amount of work being done to bring Vulnerability Exploitability eXchange (VEX) tooling into existence and helping the wider community adopt it. Ultimately, all of these projects boil down to people working together for the greater good. It is a very good thing that opportunities to get together to have the needed conversations to drive this cooperation at events like CloudNativeSecurityCon.