On the eastern shores of San Francisco, you will find The Embarcadero. Embarcadero, which means “pier” or “wharf” in Spanish, is derived from the verb embarcar, which means “to embark.” For many travelers to SF, this home to the iconic Ferry Building and Cable Car Museum is the starting point for exploring the city and the Bay. Most of those tourists are not aware that the Embarcaders is built above a ship graveyard, filled with vessels abandoned by sailors who left to mine for gold. This embarkation point was also the home to a gathering of security professionals on a journey to engineer the next generation of application security tools and best practices, which is built atop the reality that too many organizations overlook security in their rush to deliver sellable products; OWASP Global AppSec San Francisco 2024.

Over 1,200 project leads, practitioners, vendors, developers, and students were able to come together for five days of workshops, talks, and conversations all around application security. The sessions were spread across six tracks: Breaker, Builder, Defender, Manager/Culture, and the very important Project Track. That last one was a showcase of various Open Web Application Security Project (OWASP) projects from the project maintainers and contributors themselves, including JuiceShop, DevSecOps Maturity Model (DSOMM), Web Application Firewall, Software Assurance Maturity Model (SAMM), and DefectDojo.

There was a lot of amazing content, and we can't recap it all here. Fortunately, most sessions have been recorded and will be available online for free. Here are just a few reflections from OWASP Global AppSec San Francisco 2024. 

Security is built on humans trusting humans

In her keynote, "Breaking the Mold: Navigating the Intersection of Technology, Security, and Trust," Reeny Sondhi, Chief Digital Officer (CDO) at Twilio, reiterated a common theme several other presenters, including your author, addressed in their presentations: We must understand one another if we are to effectively help one another. Walking us through her background and journey to her current role. Reeny credited her time in a product management role as helping her be able to 'step into the shoes of the customer.' It is almost impossible to make things better for them without empathy for what they are going through.

She also discussed the need for security teams to become enablers. You may have heard this referred to this as going from the "department of 'no!'" to the "department of 'how'." We must adopt a mindset that makes application and product security become ubiquitous across all teams. We can do this by supporting each other's goals while working to minimize the pain that current security issues and implementing security requirements cause day to day.

Reeny said we all need to act as security salespeople internally to everyone in our organizations. We can do this by finding and presenting data in digestible ways that show the better path. We must believe that we can solve these problems and show any evidence that supports that. We must take a position that is at same the time cautious and optomstic about tooling we leverage to empower humans to work more securely. 

The danger of letting AI act on your behalf

At the beginning of his talk "Living off Microsoft Copilot," Michael Bargury Co-Founder and CTO at Zenity, explained the answer to our current dilemma with AI was written in a 45 year old IBM internal document. That document contained the words:

A computer can never be held responsible. Therefore a computer must never make a management decision.

In our rush to implement LLMs and AI everywhere throughout our organizations, we have overlooked one of the largest threats AI brings. If we pay attention to the marketing and sales materials for AI assisted productivity tools, like Microsoft's Copilot, they spend a lot of time talking about the security of the data and how their tools prevent data leaks. What they don't talk about is what can go wrong when you allow these tools to interact with your other tools as if they were you. 

Attackers are trying to deliver control instruction payloads which tell the AI to ignore your prompt and to do what the attacker wants. This kind of attack is called jailbreaking and it can get the AI to write phishing emails or worse. These attacks become extremely potent if you allow AI assistants do things like send emails or make API calls. Michael concluded with a reminder that AI is still new and therefore we are all AI security noobs. However, we must persist and learn this new area of security because AI and these threats are not going away.

Matan Rabi, R&D Team Leader at Bright, at the very beginning of his talk "How to get developers to want to adopt AppSec," asked the room, "Why do developers hate application security?" His answer is, for the most part, that they do not believe they get measured on doing things securely, just getting many things done. Security is too often seen as just extra work.

He suggested having the conversation that "a bug, is a bug, is a bug." If we are measuring output and rewarding low bug counts, then we need to frame all security issues they introduce that cause rework as bugs. We must then empower them to reduce that bug count effectively with the right tools. If we measure their output in terms of getting to production the fastest and with the least amount of rework, seeing security as bugs, we can hopefully drive their desire to work with security early and often if security teams can offer a way to do that.

However, It can't just be giving developers new tools, it will take awareness, training, and building trust with each other as human beings. Matan believes we need to start training developers to hack their own applications to understand better why it is important to develop securely. Of course, tools are needed, but they need to integrate into the developer's preferred workflow and toolchain easily if we expect adoption. If we add toil through a new layer of tooling with a steep learning curve, then nothing will change. 

Re-enforcing good developer security means rewarding their positive actions

In their joint talk "From Hype to Reality: The Broken State of DevSecOps and Its Maturity Model," co-presenters Eitan Worcel, CEO & Co-Founder at Mobb, and Dustin Lehr, Co-founder and CPTO at Katilyst, invited us to step back and remind ourselves what DevOps was trying to solve and how we have approached securty. The issue is not that developers want to write insecure applications, the reality is that security is confusing and they need help in delivering secure code. 

They reminded us of the G.K Chesterton Quote: 

It isn't that they can't see the solution. It is that they can't see the problem.

While it would be great to have a single tool or automation that would solve everything for us, they stressed that there is no silver bullet in DevSecOps. It requires people to understand the problem and put the right processes in place so people can leverage the right tooling. All of that is predicated on building relationships between security and DevOps team members. There is a solid business case for building those relationships, as we can solve problems for a lot less money if we fix them earlier in the SDLC. 

Of course, transformation is hard. It takes innovators who can see and explain the change we need to see. It requires buy-in, which we can only get by inviting people in and listening to them. If we can identify when developers do the right things and start rewarding them for taking those actions, developers will start finding new actions they can take to get more recognition and reinforced by faster times to production. This positive reinforcement loop will take time. We must be patient as we build this needed foundation for successful DevSecOps programs. 

Finding a more secure path together

OWASP exists because a group of like-minded people saw a need to address security got together and produced the tools to do that. It still exists today because more like-minded people have continued the conversation for 20 years now. The real power of OWASP is the community. Global AppSec is one of the best chances to get together with peers to talk through the challenges of today and the map the road ahead towards solving tomorrow's problems in an accessible, scalable, and open way.

But you don't need to wait until the next OWASP event to get together; there is more than likely a local meeting near you. You don't even need to be a member; you just have a curiosity about security. It is something we are proud to sponsor at GitGuardian. Hopefully, we will get a change to discuss secrets security at an event soon. 

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Code Security for the DevOps generation authored by Dwayne McDaniel. Read the original post at: https://blog.gitguardian.com/owasp-global-appsec-sf-2024/