Our journey to Strengthen SCM Security

By Raz Rosh

In today’s fast-paced world of software development, security cannot be an afterthought. As part of our efforts in the Product Security team at Playtika, we understand that CI/CD and DevOps-related security are crucial components of an organization’s overall security posture. We’ve strengthened our Source Control Management (SCM) environment with a series of proactive security strategies. While this blog post focuses on fortifying GitHub, the principles and hardening methodologies we discuss can be universally applied to other SCM solutions such as Gitlab, Bitbucket, and more, allowing any organization to enhance their security framework. Our team’s offensive and defensive approach and vast collective experience allow us to maintain a robust and secure development pipeline that keeps our SCM infrastructure secure. With that said, we keep pushing both our limits and those of the systems we use.

What We Did

1. Implementing Self-Hosted Runners: One of the first steps we took was to implement self-hosted runners while disabling GitHub runners hosted in Azure. Self-hosted runners offer greater control over the environment, enabling us to configure security settings according to our specific needs. This minimized exposure to external risks and potential vulnerabilities.
   The process to disable GitHub runners wasn’t straightforward, as our DevOps team had some back and forth with GitHub support to make that happen, but now the support team knows how to deal with similar requests, which will make it much easier for other organizations to achieve. Apparently, we were one of the first to ask this ;).
2. Limiting Repositories with GitHub Actions Enabled: To further enhance security, we limited the number of repositories with GitHub Actions enabled. Although helping and improving, GitHub Actions pose a great threat to organizations. Developers may use malicious actions from the GitHub marketplace, use unpinned actions, expose secrets via actions, abuse resources, and more. Our approach reduced the attack surface and simplified management,  ensuring that only essential repositories were allowed to leverage GitHub Actions.
3. Thorough Review of 3rd Party/Open Source GitHub Actions: Recognizing the importance of third-party components, we diligently reviewed each third-party or open-source GitHub Action before integrating it into our workflows. This practice minimized the chances of incorporating potentially malicious or insecure code into our pipelines.
4. Vulnerability and Misconfiguration Checks using Checkov: We developed a pull request (PR) check that analyzed repository GitHub Actions for vulnerabilities and misconfigurations using Checkov. This automated process helped us identify security weaknesses early in the development lifecycle, preventing potential threats from progressing further.
5. GitHub App for Scanning Deploy Keys: Deploy keys can pose a security risk if not managed properly, especially ones with write access, as they are not attached to a centrally managed account. We decided to reduce the use of deploy keys with write access to zero. For that, we created a GitHub App that scans for them, notifies developers to either delete them or migrate to a GitHub App or fine-grained token (depends on the use case).
6. Secret Scanning Tool as PR/Push Checks: Secret management is crucial for preventing unauthorized access. This was one of our biggest pains. Developers and pretty much anyone who commits code to our SCM were often committing clear text secrets, not necessarily on purpose, but sometime just by mistake when using secrets for testing. To handle this big issue, we integrated a secret scanning tool into our PR and push checks as well as scanning repositories periodically and by demand. We did one big pass to fix all the findings, ensuring that sensitive information was not inadvertently exposed in the codebase, then started blocking new PRs that contain secrets. This was probably the major friction point with our R&D team, but since we already marked false positives patterns, this made the process much easier.
7. Hardened Branch Protection Rules and Ownership Verification: To enforce a secure development workflow, we hardened branch protection rules. Requiring an owners file in the repository ensured that only authorized individuals could modify critical aspects. Additionally, PRs were mandated to have at least one reviewer, if not two, before being merged, enhancing code quality and security.

Why We Did It

GitHub is a collaborative platform where code is shared, reviewed, and deployed. Without proper security measures in place, sensitive information can be exposed, vulnerabilities can be exploited, and malicious actors can disrupt the development process. By implementing a comprehensive security strategy like the one we’ve outlined above, organizations can reduce the risks associated with using GitHub as part of their development pipeline.

Our measurements came as an additional step for the basic hardening methodologies:

1. Access Control: Limit access to the SCM environment to known IP ranges, usually your company’s offices and VPN nodes. Implement strict access controls, ensuring that only authorized personnel have access to critical repositories and actions.
2. Regular Audits: Conduct regular security audits and assessments to identify potential weaknesses and address them promptly.
3. Automated Checks: Integrate automated security checks into the CI/CD pipeline to catch vulnerabilities and misconfigurations early in the development process.
4. Educate Teams: Provide training and awareness programs to educate team members about security best practices and the importance of adhering to security protocols.
5. Stay Updated: Keep track of security updates, patches, and new features provided by GitHub, and apply them to maintain a secure environment.

Final Thoughts

Reflecting on our journey, I recognize the profound impact that carefully hardening GitHub has had on safeguarding our development processes. It’s more than just a task; it’s a commitment to security that we, as the Playtika Product Security team, take to heart. We’ve shared our path not as a prescriptive set of steps, but rather as a narrative of growth and learning. By implementing self-hosted runners, rigorously reviewing third-party Actions, and weaving automated security checks into our daily routine, we’ve made meaningful strides in bolstering our defenses. We’ve laid out these experiences as straightforward action items, hoping they serve as a starting point for others to enhance the security maturity of their environments immediately, whether they’re using GitHub or an alternative platform. Our security’s strength lies in the personal dedication and proactive stance we maintain every day.

This is not the end of our journey, but just the beginning. We are already working on more innovative features that will further enhance our CI/CD security, such as using Infrastructure as Code (IaC) for GitHub configuration and developing our own GitHub Security App. More details will be shared soon in our next blog post (;

Tags