If you're a developer, or just a sane person, audits suck. We integrated Control and Github to make them better.
Unfortunately for devops teams everywhere, auditors are starting to catch onto how applications are made and deployed rapidly in the cloud. If you're like me, you can remember the first time you fully grasped how overwhelming an audit was about to be. I was handed a 250 row spreadsheet of controls and asked by our compliance team, "do we do these things and could you send screenshots for them?" To make things worse, our legal team preemptively hired a consultant to provide pointless commentary every step of the way. This event drives us to create Control. We want to automate the auditors out of the way, so you can get back to the cool stuff.
Below you'll find the seven Github security practices that matter to auditors. Before you implement them, you should integrate your GitHub account with Control because we monitor these settings and pull the evidence for you.
Dependabotis a recent addition to Github. Long story short, it's a free security scanner that looks for security issues in the dependencies your app relies on. Is it good? Debatable. Is it better than nothing? Yes. More importantly, does it pass an audit? Yes. As you grow as a company, you'll definitely want to consider integrating a more robust security scanner into your CI/CD. A couple of good options areWhiteSource,Snyk, andSonarCloud (I'll throw inKiuwan to be a security hipster). They'll do a better job, but definitely check the box by turning on Dependabot to get started.
Go through your members list and make sure your permissions levels are right. You usually want just one or two admins, your biggest brained developers as maintainers, your lesser brained devs as write, product guys as triage, and customer support with read only. The goal here is logic based access. Ask yourself, do you trust this person with the level of access they have? If not, downgrade it.
Protected branches make pushing code slightly more painful, but vastly more secure and stable. Protected branches are not only good for security, but for uptime. These are the things you should do with them:
Require Status Checks to Pass Before Merging
Require Pull Request Reviews before Merging
Require Review from Code Owners
CircleCIis a great additional tool to run your test phases on, but you can also useGitHub Actionsfor this. There are a ton of ways to run these tests, do what makes sense for your organization, here are some things I've seen: hosting your own EKS runners, using CircleCI, or usingGitlab. I didn't say Jenkins for a reason. Shots fired. Please just don't use Azure Pipelines.
One of the coolest things DevOps teams are doing is deploying infrastructure as code. There are actually a ton of security benefits here: backups don't matter (much), you can security scan your code, and you can handle uptime easily. Control still pulls all this in and checks off the relevant controls for doing so. We've even had auditors skip reviewing the actual infrastructure because they audit the terraform instead. This is dope stuff that our competitors aren't doing.
Encrypted secrets are super important for preventing major data breaches. Manage your secrets in the settings page, not in plain text in your repo. If you use Github Actions, pull the encrypted secret in as a variable from the settings page. When you deploy, make sure you're injecting secrets through something like AWS Secrets Manager or Hashicorp Vault, not just lock and loading the variable in plain text from your repo. Also, remember that your dev's access is just as good as their secret key access: make sure you're clearly communicating how to store and rotate their keys.
Go to your org settings and require 2 factor authentication to access your repos. MFA is the easiest one click security measure that drastically increases your real security. MFA was the secret behind when Gabe Newell gave his password away in 2011 and no one could hack his account, this same secret can be yours today. No, as FireEye just learned, MFA does not make you unhackable, but it sure does help.
Here are just some cool things you should look into doing if you have a dedicated security team and are really trying to push the frontier on git security:
Host your own git so you can pipe the logs into a SIEM and write content for it.
Use multiple security tools to scan during the CI/CD process and make it so if an error code pops, the build gets blocked.
Use security scanners on your K8s nodes that are container aware so they're actually doing something meaningful (i.e. not AWS Inspector). Prisma Cloud is cool, but Palo bought this product so it's expensive now.
Here are some takeaways: This stuff is hard, and we have teams of engineers focused on it full time, so you should use us for guidance. Configuring all of this is one thing, but monitoring for it and collecting evidence for it is an ongoing nightmare, so let us do that for you. We're here to help you get through the audit, and provide real security, not just security theater.
“We want to automate the auditors out of the way, so you can get back to the cool stuff.”
Start with Security Foundations for free and automate everything you've read in this article, plus:
Prescriptive Tasks so you know where to start.
Cloud infrastructure and SaaS security scanning.
Automated security policy creation.
Automated evidence collection for future audits.