This article was originally published on GitGuardian’s blog.

I joined GitGuardian in July 2022, one year ago. Since then, I’ve worked hard on improving existing security processes & building defense mechanisms.

Now is a good time to reflect on GitGuardian’s security team’s achievements and failures over the past year. I hope this post can shed some light on how our team does things and help your organization raise its security level.

The elephant in the room

Let’s get one thing out of the way: GitGuardian is a security company. We develop and sell software used by security specialists & tech-savvy folks all over the world. So, yes, expectations are high. You would think my job as a security leader is harder; it is in fact much easier!

Guardians understand the risk associated with what we’re doing here, they proactively seek advice from the organization’s security leaders to make our systems the most robust they can be. I honestly could not ask for more.

Very early on, the company has put in the necessary efforts to design & enforce essential protection mechanisms. I can definitely say I was impressed by what I saw in my first few days here. But I was not hired to praise my colleagues’ work, I had a job to do.

Scaling security

The devil is in the details. Security is too.

In a small organization, complexity is usually manageable, so manual checks & workflows definitely work. But as the organization grows, complexity increases exponentially, and security risks fester.

I’m deeply convinced that reducing the cognitive load my fellow engineers have to carry is key to advancing security practices in the company. So my job at GitGuardian is to ensure the ever more complex socio-technical systems we operate keep running efficiently and securely without overwhelming my coworkers with security requirements & checklists.

To achieve my goal, I have gone all in on standardization, automation & documentation in a bid to reduce the number of details to comb through in search of risks and breaches.

Growing the elephant

So how do you go about building a scalable security program for a security software company? Well, I started by leveling up the fundamentals.

Inventory

You cannot secure what you cannot see.

One of my first steps at the company was updating our vendor list. To ensure the system scales, we worked on improving the workflows operated by other teams (eg. legal & finance) to ensure all new vendors go through the security due diligence process and get added to the vendor list.

Then we focused on maintaining our production assets inventory. Thankfully, that was easily automated thanks to our security management software. We could now see the big picture in terms of risk exposure.

Secrets

Leaked passwords are a danger, we know that, we’ve made a business out if it! We’ve equipped ourselves with a password manager from day one. Unfortunately though, the service we had was neither user-friendly nor admin-friendly. That is not acceptable from a security perspective. Good UX makes for good security: Users will always take the path of least resistance ; as security professionals, we must recognize that and work on making that path the secure one.

So out went the old password manager, and in came the new one! The migration was not straightforward as we needed every individual to move their own private vault. We made automated tools available and a how-to guide to ease the transition. It was carried it out successfully over several weeks. We could not be happier with the end result.

Workstations

Workers’ workstations usually are prime targets for initial compromise. Securing them may not be as sexy as configuring the next-generation cloud intrusion detection system, yet it’s an absolute necessity. I made sure we spent enough time with the IT team to go over their hardening process and workflow automation, looking for and fixing potential security misconfigurations.

Identity and Access Management

This is the big one. Having seen how ineffective IAM slows down an organization, I made it my mission to upgrade GitGuardian’s system to embrace (near) total automation.

Using Terraform & automated workflows, my team and I are working on eliminating the friction & frustration created by centralized manual permission management. Users can now be onboarded & offboarded in minutes, with little effort.

The real kicker though is that users at the company can audit & contribute to our IAM automation system with a mere pull request. The code is freely available internally, and documentation allows anyone to suggest changes to that codebase to tailor their permissions to their needs. Doing so moves security people out of the proverbial ivory tower and onto the engineering terrain, and that’s not such a terrible thing.

Security awareness

Utter the words “mandatory security awareness video” and it’s likely some people will roll their eyes.

At GitGuardian, we’re convinced that the security responsibility does not solely fall on users’ shoulders. Yet, good security trainings are unequivocally effective at getting the user to react when other measures fail.

The key word in that sentence is “good”. To make our security trainings actually good, we’ve invested time and effort into crafting 3 separate workshops (trainings for everyone, for engineers & for product managers) collecting feedback and continuously improving our workshops. We’ve paid particular attention to keeping Guardians engaged throughout.

This has paid dividends. Following the trainings, we started getting requests for help designing protection measures in various systems throughout the organization. Teams were, of their own volition, proactively fixing security problems within their scopes. The icing on the cake was the Net Promoter Score for our workshops: +39. For corporate security training, that’s a major win in my book.

Pain points

While we’ve beefed up some baseline components, all is not perfect at GitGuardian’s security team.

IAM is hard

Rolling out RBAC for new applications using the automated IAM system is still a chore. Various teams at the company have added new tools in the past months, and it hasn’t been easy getting these apps to work with our automation system. Some refactoring might be necessary.

Making tooling available and understandable

Security through obscurity is nearly always a bad idea (except for passwords, obviously). Transparency is important in our field. It allows users to understand their risk and act on it. At the scale of our organization, having Guardians understand and use tooling usually reserved for blue teams (e.g. scanners, WAF, GitGuardian Platform) ensures the company as a whole extracts maximum value from all these tools, and forces the security team to improve their internal processes to match users’ expectations.

We are currently failing at this objective. Most of our tooling is still restricted to the security team, and that’s a slippery slope towards siloisation. We know we must improve on that aspect.

Vigilance fatigue

In this article, we’ve shared a few of the projects we’ve been working on. Much more is going on behind the scenes to keep the lights on.

Managing external audits, triaging bug bounty reports, responding to alerts are all activities our team does, and they are not always seen by other Guardians. They’re not flashy, and they don’t directly contribute to automating security. Yet they are part of the fundamentals, and the difficulty is in addressing them properly while keeping our core security people and partner teams engaged, not burnt out, and ready to contribute.

We haven’t solved vigilance fatigue yet; we are guilty of the occasional slip-up. We’ll report back if we do manage to figure out this puzzle

Socio-technical systems

“People, processes, technology” is a phrase we’ve all heard ad nauseam. I do not like it. It implies a separation between these elements and sets the order in which to tackle problems.

A software company is a web of socio-technical systems. A shrewd security leader recognizes that and applies systems thinking to push security forward in their organization. Again, it’s easier said than done, but it is what our team is striving for here: integrating security seamlessly into our systems, making sure it lives and breathes with our main product with as little intervention from us as possible.

We don’t just want to “shift left.” At GitGuardian, we want security to shift left, right, and center.