GitHub Scanning for Policy-as-Code Configuration Validation

TL;DR

We just enhanced Styra Declarative Authorization Service (DAS) with a feature customers have been asking for: near-instant scanning of policy-as-code config files right in GitHub. …Oh, and as a bonus, it’s free, it’s available now and it only takes a couple minutes to see live in-action in your repos!

If you’re familiar with Styra DAS, then all you need to know is that this new Repo Scanning feature gives DevOps teams a near-instant solution for scanning policy-as-code files directly in GitHub. Styra DAS can scan as soon as code changes are made, or any time throughout the software deployment process, which means:

• A new, simple, “shifted-left” scanning function, to find errors within seconds of deployment
• Streamlined compliance reporting to help manage the right priorities, and prove that errors or misconfiguration has been fixed before production
• Enhance productivity with “write-once, use many times” portable policy enforcement — from GitHub check in, to CICD, to production deployment

Not already a Styra DAS expert? Read on to learn:

• Why our customers asked for Repo Scanning
• What Repo Scanning does for DevOps
• What to expect when you sign up (for free!)

Why Does DevOps Need Configuration Validation in Github?

Today’s apps are built from hundreds, often thousands, of discrete components, and these components can come from anywhere — internal developers, external contractors, Open Source Software, commercial tooling and more. 

Not only that, but all these services are run in — and managed by — cloud infrastructure. All the components, and the infrastructure are governed and controlled by all sorts of tooling and automation, all of which is managed via thousands of lines of configuration, spread across multiple files, languages and systems. Yeah, it’s as complicated as it sounds. 

Managing the vulnerabilities that come from upstream code is a key component of “Software Supply Chain Security” and has led to many vulnerability scanners that look for known issues, and flag them for action before they cause too much risk. And as a former IT person myself, I can say easy things like “Scanning for vulnerability is never wrong.” But scanning for vulnerabilities within services is just one step in securing your software supply chain. 

Before Policy-as-Code and Configuration Validation

Back in the day, as a young IT do-gooder, I knew that stopping known exploits was important. My team spent lots of money and time on code scanners, prioritizing vulnerabilities based on current exploits in the wild and worrying about clever attackers doing clever things.  

But you know what actually brought us down? A misconfigured firewall that allowed access to the corp network, from the test network. You know how we caught it? The test network was opened to the whole big, wide, Internet by a well-intentioned engineer who wanted to work remotely for a week. Mm-hm. That really happened. It was… not good. No cleverness required— bad guys got in right through the front door. Well, side door really, but you get the point. Thank goodness for defense in depth, but that’s another story for another time.

Automate Configuration Checking to Prevent Errors

Even when all we needed to do was look through a few hundred lines of firewall rules on two connected boxes, my old team still missed errors. Now, platform and security teams have infrastructure that’s is far too complex to be managed with point-and-click interfaces (admins like me would be diving through hundreds of menus configuring thousands of choices over and over), and instead it all must be controlled through thousands of lines of purpose-built code that defines the configuration of each system.

It has become the case that no human can keep up with checking that config code, over and over, to ensure configuration changes and app updates don’t have unintended consequences. We have to automate this process, as part of our software build, every time. And it’s not a “just check it at the beginning and you’re good” situation. Code should be checked early, but also often — to catch errors, eliminate conflicts, and generally be sure that governance is in place everywhere it can be…  without creating make-work or manual overhead, of course!

Basically, software supply chain security doesn’t stop at scanning for exploits in upstream code. It also includes verifying that your configuration is good, works as you intend and doesn’t introduce its own risk. Misconfigurations and human error, multiplied across the thousands of lines of code required to manage today’s cloud platforms, introduce incredible risk to app performance and security

Styra DAS Configuration Validation In Action

So we all agree that DevOps teams need a unified, consistent, cross-platform way of validating and enforcing policy-as-code across clusters, clouds and teams. Great! Sounds like a perfect use case for Styra DAS. So… how does it work?  (I promise it’s easy, and it will likely take you longer to read this than to set it up in DAS Free.)

• Go sign up for Styra DAS Free. It’s Free. You probably guessed that.
• Choose Scan a GitHub Repository, and then Select a github repository scope (either just public, or public and private repos).  

3. Authorize Styra DAS to scan your repo (note the read-only access!)

4. Then just Choose a repository to scan as below.

5. When the scan is complete, you’ll see a list of compliance violations, based on best practices learned from security experts, Styra customers, the OPA community, and a host of auditors.  (See how clean my environment is below?  What, you thought I’d show you my errors after that firewall story above?  I can’t be that emotionally vulnerable all in one blog! 😅)

And that’s it! 

Our customers asked us to provide the value of our OPA-based policy guardrails to DevOps and Dev teams as early as possible, to minimize cascading errors, rework and risk to production systems. 

Of course, Styra DAS still enforces policy in CICD, and then also at implementation time in Admission Control or cloud run, as well as in running clusters or platforms… you get the point. It’s the power of portable policy, and that’s not just alliteration; it’s actually useful!  

Bottom line: Styra DAS can flag, block or remediate issues it finds at multiple times along the software development lifecycle, to minimize risk. But most importantly, teams can get actionable feedback when it is right for them.

But as Geordi La Forge famously said, “You don’t have to take my word for it!”  Go check it out for yourself in Styra DAS Free today!