The software development lifecycle and CI/CD pipelines are becoming clogged with a neverending list of tools and scanners. Code quality testing, Static or Dynamic Application Security Testing (SAST/DAST), hardcoded secrets detection, Software Composition Analysis, infrastructure automation, IaC scanning, etc. No field or area doesn’t have a tool that can’t integrate into Version Control Systems (think GitHub OAuth apps) or CI workflows (think Jenkins plugins).
With every new addition to the software development toolchain, developers, infrastructure, and security teams must ask themselves, “what value are we getting out of this tool vs. how much time can we afford to spend on running it.” In the case of application and infrastructure security tooling, every scan translates into findings (vulnerabilities or weaknesses), and every finding needs to be prioritized, investigated, assigned, remediated, closed or followed up on, and reported. Add in a few manual tasks at each step, multiply the time spent on each by the total number of results from every scanner, and you end up with a cognitive load that overpowers even the most determined security engineer.
Automation is critical for security teams to reach a productive (and happy) state. And GitGuardian aims just to provide that experience for every organization committed to tackling hardcoded secrets in the software development lifecycle (SDLC). With GitGuardian’s playbooks, security engineers can automate alerting, prioritization, and collaboration tasks–without logging into their workspace.
Let’s go over a few and briefly explain what about them gives application security engineers an edge when grappling with vulnerabilities in code.
(Automate) severity scoring for hardcoded secrets
Getting your priorities right is not straightforward regarding hardcoded secrets, especially when there can be hundreds or thousands of them in your repositories’ commit history (some are more than a decade old!). Many factors come into play, and things can get tricky.
With this automation, GitGuardian handles incident severity scoring, so security engineers can identify and charge through the most critical ones first. In the background, GitGuardian will go through each incident and assign a severity based on the recency, validity, presence, type of secret found, and other incident metadata.
Dwayne McDaniel, Security Advocate at GitGuardian, put together this short demo of the feature in beta.
Update: In February 2023, Automated Severity Scoring went out of beta and became generally available for all GitGuardian workspaces. Learn more in this blog post.
Ziad Ghalleb
(Automate) access granting for developers
Application security should put developers front and center for effectively tackling hardcoded secrets because they own more context than anyone else on the team. Since they were the ones to check secrets into source control in the first place, developers can answer questions like “what type of resource does this secret protect?” or “how sensitive is the data in this now exposed system?”
To bring security and development teams together, GitGuardian offers a practical playbook to identify involved developers based on their commit author email and grant them access to view their incidents directly in the dashboard. Once in, developers are asked to provide feedback on the incident and contribute to accelerating the “revoke and rotate” steps.
With this automation, security engineers are no longer alone in incident remediation and can rely on the help of developers without having to ask for it.
What is particularly helpful is that having GitGuardian show that the code failed a check enables us to automatically pass the resolution to the author. We don't have to rely on the reviewer to assign it back to him or her. Letting the authors solve their own problems before they get to the reviewer has significantly improved visibility and reduced the remediation time from multiple days to minutes or hours.
Danny Cairney, Chief Software Architect
You can learn more about this playbook in this 1-min video by Dwayne McDaniel, our Security Advocate.
(Automate) closing hardcoded secrets incidents
The GitGuardian bot will continuously crawl open incidents to check if their secrets’ validity has lately changed. If it crosses paths with incidents containing recently revoked hardcoded secrets, it will close them and record a log (how polite!).
Sure, your hardcoded secrets will not revoke themselves, but at least GitGuardian will close your incidents once developers have finished their work. With this automation, application security engineers can go back to focusing on the remaining open incidents.
GitGuardian users tout this playbook because it doesn’t only apply to real-time monitoring incidents. Once activated, it will also close all incidents found in the distant commit history of their repositories–in one burst!
Automation doesn’t have to stop here
In addition to out-of-the-box automated workflows and playbooks, GitGuardian provides security engineers who value the power of scripting with a public REST API. Our philosophy for the GitGuardian public API is pretty simple. Every action a user can make from the UI should also have its equivalent REST API endpoint.
Last words
Tackling hardcoded secrets in software development is a big undertaking for most application security teams. But with clear eyes, full hearts, and a great dose of automation, we believe they can’t lose the fight against secrets sprawl!
If you’re still in doubt about adding *yet another security scanner* to your developer and CI/CD environments, read our wake-up call for application security leaders: Why it’s urgent to deal with your hardcoded secrets?
