This article was originally published on GitGuardian’s blog.

It’s been now 2 years since I started working for the Owl, and my goal has not changed since: provide the best security guardrails that allow for maximum velocity.

Over the past 12 months, we’ve had plenty of challenges, and successes too! Today I’ll be sharing with you the highlights of our year.

The elephant is still in the room

Last year, I said my job is easy. It still is, even if a bit overwhelming. Let me explain.

We’ve added new Owls to our ranks. Per the law of large numbers, you’d expect our employees’ security awareness to converge toward the true mean. It hasn’t. We’re all still a very security-savvy bunch!

The downside is that I have a lot of requests: questions like “Hey, how should we handle this?” and “How can we make this feature safer?” are very common from engineers and product managers. And I could not be happier!

The challenge I see moving forward is making sure the security team is not a bottleneck in this type of discussion. But we’re not there yet.

The successes

Stronger SDLC

One of our main focuses this year was improving the security guardrails around our Software Development Lifecycle.

Security engineers can’t check every pull request. It doesn’t scale and doesn’t allow for maximum velocity. Automated checks do. So my team and I have invested time in bolstering what we already had.

We’ve expanded our SAST scanning with more rules and added GitGuardian’s own SCA tool to check for vulnerable dependencies. We’ve also introduced a new DAST that runs daily on our preproduction applications and checks the live app for any vulnerabilities that may have been missed.

You may know that we’re already Chainguard customers, and depend on them to provide us with 0 CVE base images. We’ve aligned our own container security scanning with Chainguard’s standard. Our new internal container scanning pipeline powers dashboards & alerts that feed into our existing vulnerability management workflows.

Better security observability

In July 2023, the security team relied on GitGuardian’s main centralized log management system to store and process security logs. Detections were difficult to write and maintain, and dashboarding was a significant pain. GitGuardian’s engineers depend on metrics for most of their observability, and only use logs for occasional debugging.

So the security team decided to switch, and we’re happy with our move. We went for a self-hosted system with an SQL-like query language, and an API that makes it easy for us to update our detections. Maintenance is now a breeze, and so are our investigations.

More dynamic secrets

We know everything about secrets, and we like them to be dynamic. This year, the security team continued its investment in dynamically generated secrets and expanded their usage within the company’s technical systems.

We now have dynamic credentials for our VCS, our data stores, our cloud provider, our app runtimes, our docker registries, and the list goes on.

The challenges

It hasn’t all been fun and games, though.

User experience

Maximum delivery velocity requires the best user experience. We have to keep improving on this point.

Yes, dynamic secrets are great, but are they accessible? Are they easily available to those who are authorized and who need them?

To solve this, the security team has teamed up with the developer efficiency and platform teams to improve the user experience for the rest of GitGuardian’s engineering, thanks to a user-friendly internal CLI tool that handles common workflows with a single command.

We’ve made fantastic progress, and we can still improve the UX for all our engineers.

We want to ensure that the easiest way is the secure way.

Aligning priorities

Priorities are difficult to align across an organization with teams that have differing ownerships. This is a classic problem, and it gets bigger as organizations grow.

Sometimes teams need to move forward quickly, and can’t afford to wait around for a decision or another team to implement something. This could have security impacts, depending on what’s at hand.

This year, teams at GitGuardian have moved fast and broken things, and that also includes the security team! And honestly, that’s alright, as long as we’re able to recognize and fix mistakes. I’m happy to report that we were.

Did we succeed?

At GitGuardian, we want security to shift left, right, and center. My team strives to integrate security seamlessly into our systems, making sure it lives and breathes with our main product with as little intervention from us as possible.

So did we succeed?

Yes, I’m convinced we did. I’ve got many examples of teams that have taken initiatives to improve their security, without us knowing. I also have numerous examples of engineers who have gone above and beyond to make their systems more security-robust.

We’re on track to building a lean, mean, security machine.