Back

Number 9: Ownership – Security Guardrails Series

In a modern world where applications are being shipped faster than ever, ownership is the foundation (oh yes we are making that claim and we really mean it) for application security folks to keep up with development teams. Think about it in just one example (out of many) of a code related incident where there is a vulnerability and your application security team (of like two people) have to track down who the heck last touched that piece of code. Nigh impossible!
read

Defining up-to-date ownership of pieces of code or an entire codebase holds folks accountable and allows security teams to have clear action. Instead of spending hours/days tracking down which developer owns or can help remediate a vulnerability. Imagine a world where you set up security guardrails that only allow code to be deployed if an owner is declared and there is associated metadata for each repository. Shocking, right?!

Not only does this translate just to snippets of code or an entire codebase, but also the infrastructure that is being deployed to support it. Can you see a world where security and development teams have container, asset, repository and team ownership data?

Using about.yaml and Gordon from Twilio or CODEOWNERS file in Github can be a phenomenal first step in defining ownership. But, the next step is automating proper ownership security guardrails to make it adoptable for developers during the SDLC and even more importantly reducing the time spent for security teams when ish hits the fan.

And while this ownership needs to start at the code level, we all know that code is built to eventually get deployed as artifacts and systems somewhere. So you may want to start at defining code ownership, don’t stop there. We’ve seen teams get most benefit out of this when you go beyond code ownership and also build attribution of artifacts to the code owners. Only then you can find out not just who owns the code, but also who built a particular container, who’s the owner of a service and what’s the codebase associated with it.

If this sounds like something you want to implement at-scale, just hit that “Request Demo” button on the top right of the page, DM us on Twitter, or on LinkedIn and we will set up time to chat about it – maybe let us know you read this post. It would make our team super happy!

Stay tuned for our next one up, Number 8: Approved Dependencies!

Past blogs in the Security Guardrails Series:
Intro blog – What the heck are Security Guardrails and why are they important?
#10: Tags

Upcoming blogs in the Security Guardrails Series:
#8: Approved Dependencies
#7: Approved Container Images
#6: Vulnerabilities
#5: Scanning Tools
#4: OSS Licenses
#3: Auto Update Dependencies
#2: Code Reviewers
#1: Branch Protection

Rate this article

Recent articles

How Do You Justify Investment In Product Security?

How do you justify investment in product security? On a recent episode of the Future of Application Security, FullStory’s VP of Product Security and Compliance, Mark Stanislav...

Read more
Should You Outsource Product Security Maturity Modeling to a Third Party?

Should you outsource product security maturity modeling to a third party? On a recent episode of the Future of Application Security, FullStory’s VP of Product Security and...

Read more

Ready to Scale Your Product Security Program?

Sign up for a personalized one-on-one walkthrough.

Request a demo

[email protected]

Request a demo