DevOps productivity series — GitHub for DevSecOps

GitHub & DevSecOps Productivity Tips

This article was originally published at ShiftLeft Blog.

My colleague Andrew Fife wrote about our passion to focus on developer experience and productivity with our NextGen Static Analysis platform. Productivity, just like Security, is not a one-time activity but is a continuous journey that requires frequent optimization at every step. Alright, there are some integrations and productivity features in our SAST platform out-of-the-box, but every team and developer are different so like security even achieving a good productivity is a shared responsibility. When combining technology with processes is when organizations will achieve the biggest productivity gains.

Any DevOps and DevSecOps journey start with the obvious Dev. The primary tool for developer collaboration is a good git platform. One of the things that always puzzled me is that while Git core is decentralized all the git platforms are centralized — modeled after the hierarchy seen in the real world — with administrators, code owners, maintainers. During my consulting career, I have always wondered how little configuration changes teams end up making from the vendor’s defaults.

In this series, I will be researching and sharing the hidden treasures, those configurations and scripts that could help your team with the DevSecOps journey beginning with this post about GitHub.

Say Hello to Terraform

Is your GitHub administrator still using the UI for creating repos and managing teams? They’re doing it wrong!

Instead, terraform is a great tool for working with GitHub. Yes, there is an initial learning curve and investment in code involved. There is also a risk of downtime and accidental damage. But you can always experiment with a new test organization before trying with the real one. Even if terraform is not your thing, any automation via API and CLI is better than no automation at all. The new add application experience on ShiftLeft in fact uses a combination of v3 REST and v4 GraphQL APIs for that easy integration experience.

ShiftLeft add application experience

Terraform GitHub provider can be used with only a personal access token belonging to an administrator. My example terraform module for GitHub can be found here.

Some use cases, I could think of.

1. Rolling out branch protection policies across repositories

The below script would protect your master/main branch from accidental merges. PR would be allowed only if certain status checks such as tests and shiftleft are complete. As an added bonus, the script would allow development managers to override as a last resort.

2. Creating rolling repository secrets

I often hear stories about secrets being passed around and pinned onto a channel in slack. This approach is in fact worse than passing passwords on sticky notes around since viewing passwords from sticky notes requires a physical presence! The below snippet can be used to create secrets for GitHub actions directly with terraform.

It is currently not possible to create organization secrets using terraform. Use the REST API for this scenario. Now all your secrets can be rolled over and changed periodically based on your security needs. Bye bye slack!

3. Rolling out GitHub actions across a number of repositories

Refer to my example repo here which is used by our customers to roll out ShiftLeft across GitHub repositories. The workflow files are conveniently stored as templates in a data directory. Feel free to fork this repo and replace the workflow files with your custom version.

4. Slack pull request reminders

This clever productivity feature is not available via API yet and hence needs to be configured manually. Ask your administrator to follow the steps in this document.

Use Repository Templates

If you create empty repositories and let the developers and teams populate it with code then you’re doing it wrong.

Instead, produce example applications and services including CI, lint and SAST configuration for a handful of application categories and publish them as Repository Templates. You can also fork one of the existing well-known templates and add your custom configurations in them.

Every application and services developed by an organization can be grouped in various forms such as:

  • Java Spring Boot Micro service + docker with Jenkins and AKS
  • Node.js backend with React frontend
  • Android Kotlin app with Circle CI and Firebase

Each of these repos would require the following:


  • Teams
  • Branch protection policies


  • CI/CD configurations
  • Repository secrets
  • Linting and formatting rules
  • SAST and other security tools configuration


  • Example code with unit test

Roles and team membership can be created with Terraform or API. The key is choosing the grouping tags carefully. When done correctly new repo creation can be fully automated via Terraform or API.

Customize the query in the snippet above based on the topics and language needs. Bonus points if this script can be wrapped into a service or a bot for fully automated repository creation based on requirements.

Use GitHub Actions for unconventional automation

Many people wrongly assume that GitHub actions is just a CI/CD product.

GitHub actions is also a nice general purpose automation tool and can be used to improve productivity as part of your workflow.

Below are some productivity enhancing ideas with GitHub Actions.

Performing tests as part of predeployment

Pull Requests (or Merge Requests) based workflows are quite popular and rightly recommended as an anchor point for reviews and testing. However, in certain non-security cases it is perfectly fine to allow merges to happen and perform testing only before deployment to live environments. I have recommended this model while integrating work from many teams into a common branch before testing could commence. GitHub actions can be used to perform activities such as security scan in such a post-merge pre-deployment scenario.

Simply use deployment instead of pull_request.

With little more effort, it is possible to perform activities only based on the presence of certain labels such as “Ready for static analysis” or “Ready for AppSec”.

Notice the if condition that is looking for a specific label to be present in the pull request before performing the scan.

Setup code scanning

GitHub code scanning is both a security and a productivity feature available for free for all GitHub users. ShiftLeft partnered with GitHub from the ideation phase and helped in designing and building this neat feature. This is an excellent way to get started with DevSecOps processes and maps well to OWASP ASVS Level 1.

Adding ShiftLeft Scan with GitHub code scanning
Adding ShiftLeft with GitHub code scanning

Don’t Bother with Templates

This one is going to be controversial for sure. People love to hate Jira because of the time it takes to fill the form fields. Now they ask for the same values in the form of a markdown for issues and pull requests on GitHub!

From my personal experience, issue and PR templates don’t make much of a difference either way. I have witnessed numerous projects actively triaging and responding to issues without any templates. In contrast, I have experienced projects with well-thought-out templates but no activity or time commitment from the author.

The key is getting developers to buy in. If you feel that an issue/PR template or a structure is not helping your team, then feel free to remove it. If you feel that templates would help better organize, track and motivate the team, then add them in. Either way, solicit feedback from your developer because there’s no point in building something they won’t use.

Closing Thoughts

I have ignored certain configuration and tips that are entirely security related such as the ability to choose default privacy level for repositories, built-in secrets scanning feature and so on. I have also ignored certain obvious tip such as using Dependabot or Renovate to manage dependencies. Personally, I have not felt the need for an external service that would take all my source code, dependencies and secrets in return for a free service. This is the whole reason why ShiftLeft as a company even exists — all our products work without the need for ever copying your source code to the cloud — a technology that we invented, built and shared with every one.

In the next part, I will be delving into Bitbucket in detail and share some tips for DevSecOps. Stay tuned!

DevOps productivity series — GitHub for DevSecOps was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Prabhu Subramanian. Read the original post at: