Building software is analogous to building a car or a plane. These large, complex physical machines are assembled from a huge number of smaller components, using a series of well-defined manual and automated processes. It’s hard to imagine manufacturing cars without standardization and replicability. For each car you’d need to cobble all the individual components from scratch. Your team would have to blow glass for the windshield, devise door-locking mechanisms, and literally reinvent the wheel—every single time. Even if they came up with a clever and efficient procedure, no one else at the factory would benefit from it. 

And yet this nearly unimaginable manufacturing scenario is common in software development. All too often, engineering teams working on new applications start from scratch, even when components and automation tools that could make the process faster and more fun already exist. There is a huge opportunity to create more reusable building blocks that enable organizations and developers to build software effectively—so long as those development teams can find them.

At KPMG, GitHub serves as a beacon to attract developers across member firms in different geographies to get involved with projects and collaborate with teams they might otherwise never have discovered. Before GitHub, no one at KPMG could view code produced by other teams, let alone comment on it. Siloed codebases meant our developers couldn’t learn new skills by examining other teams’ code, or submit improvements, or customize it to their needs.  Now, small teams and even individual developers can have a greater impact by sharing their code with other teams across KPMG or contributing to existing projects created by other teams. Our NPS scores for the work environment pillar, focused on developer experiences, have increased by 20% over the last year. 

To extend the impact of this unified codebase, we initiated an innersource program and embraced a product mindset when it came to security, which enabled us to leverage reusable code and processes to create secure software efficiently. Here are a few lessons we learned along the way that we hope other organizations can leverage.

In this Guide, you will learn:

1. Best practices for launching an innersource program

2. How you can use automation to make your innersource program more successful.

3. How to use automation to productise your information security.

Why innersource?

KPMG started our innersource journey with GitHub to help our developers not only build software more effectively, but to spend more time writing meaningful code. Every idea starts with code and developers at KPMG are at the core of bringing these ideas to life. Software is created, infrastructure is managed as code, and security policies are written as code. Even the engineering mission, vision statements, and goals are expressed in markdown so we can iterate and collaborate on them constantly.

However, we identified that developers spent only 30-40% of their time actually writing code. This was partially due to time spent recruiting and onboarding other engineers, troubleshooting issues and incidents, and dealing with security issues. We realize that it’s neither feasible nor desirable for our developers to spend 100% of their time on code. Engineering is a creative profession that requires engagement with a diverse array of people from practically all areas of the business. But we want our developers spending as much time on what they were hired to do: write code that solves business problems. 

To address these issues and maximize the impact of our developers, KPMG built the KPMG Code Platform, a shared library to encourage collaboration and code discovery and reuse, using GitHub and other tools. Now, engineers are onboarded on day one. They are empowered to find and start contributing to projects as early as possible. All engineers can reuse other components, libraries, and frameworks, enabling them to connect to others working on similar projects. For example, teams at KPMG Finland and KPMG Japan discovered each other’s projects through GitHub and joined forces to create the Cloud Next project, a way to manage Public Cloud platforms effectively. These changes improved the overall developer productivity and happiness within KPMG. 

Putting innersource into action

Start small. You can’t change your entire organization at once. At KPMG, there was no innersource big bang. Instead, we started out by identifying a few teams that were interested in experimenting with innersource. My technology team at KPMG UK kicked things off by using GitHub to share code internally. GitHub Enterprise Cloud was just the start of our journey. We have focused on growing and improving collaboration by engaging established communities. The community focus has brought us:

1. Better and more findable documentation,

2. Clearer contributing processes, and,

3. Overall, better internal transparency

Once we had a few demonstrated successes, such as the KPMG Finland and KPMG Japan collaboration, we were able to use our experience as a model for spreading innersource culture across our member firms.

Takeaways:

• Don’t try to change your whole organization all at once. Find teams that are already interested in open source and partner with them.

• Try a few experiments and use the successful ones as models for other teams.

Create innersource standards for your organization

Rather than try to force teams to work in a particular way, we’re working to make innersource the path of least resistance when creating software at KPMG. But great innersource programs don’t just happen. One of the biggest lessons we learned is that if you want teams across an organization to create and use innersource software, you need to provide guidance about what “good innersource” actually looks like at your organization. If you want your innersource program to succeed, you need an innersource policy not unlike your open source policy that covers legal requirements and best practices. This policy should include:

• Licensing information. For example, KPMG has two types of licenses. One for code that can be used internally or in projects or clients, and another for projects that we plan to commercialize and can only be used for testing or for specific projects.

• Documentation requirements. For example, the need to include a list of code owners in a README file.

• Branch protection and other change management requirements.

• Code hygiene expectations.

The goal is to make it as easy as possible for teams to adopt innersource solutions. When a developer discovers a repository created by another team, they should be able to quickly find out what the software does, how they can and cannot use the code, whether and how they can contribute back to the project, and who to contact with any questions.

Your policy should emphasize making communications as visible as possible through things like roadmaps, documentation, and open discussions on pull requests.

Takeaways:

• Don’t expect teams to adopt innersource best practices without guidance. Create an innersource policy, not unlike your open source policy.

• This policy should cover both the legal and compliance aspects of innersource at your organization and the practical aspects of development, like documentation requirements.

Don’t just prescribe: Automate

Policy can be a double-edged sword. On one hand, you want to create policies that make life easier for developers. But policy has the potential to create new compliance burdens on developers who just want to write code. Fortunately, you can automate policy to alleviate potential toil. For example, at KPMG we implemented a GitHub Action that creates a pull request with a suggested license for any new repository that doesn’t have a license within a set number of days. This ensures that all repositories have licenses without requiring employees to spend time combing through internal repositories verifying that they do, or requiring cumbersome project creation processes for developers.

Takeaway:

• Automate policies wherever possible to reduce both human error and developer toil.

Productize security

Writing code faster is great, but every organization has to mitigate software security risks. Traditional approaches to managing security risk, such as manual point-in-time assessments combined with often cumbersome and outdated controls, can lead to delays in delivering value. They can also cause significant friction between information security and engineering if engineers see security as an impediment to their work.

One way to reduce this friction while ensuring that you can securely deliver value through technology is by productizing security within the SDLC. You can start by treating your security policy as code, just as you can your innersource policy. For years KPMG has used GitHub to share and collaborate on our compliance policies. From there, we were able to automate compliance in many cases. GitHub Actions and GitHub Advanced Security are a powerful combination for this. Below is an example of a workflow file that pushes vulnerabilities detected in an Infrastructure as Code templates and allows engineers to use the same GitHub UI workflow to manage (resolve, dismiss, etc.) these vulnerabilities as the rest of the codebase. 

# You can call this workflow using the syntax

# jobs:

#   tfsec:

#     uses: KPMG-UK/github-actions-library/.github/workflows/tfsec.yml@main

name: 'Tfsec'

on:

  workflow_call:

jobs:

 tfsec:   

   name: Run tfsec sarif report

   runs-on: ubuntu-latest

   permissions:

     actions: read

     contents: read

     security-events: write

steps:

     - name: Clone repo

       uses: actions/checkout@v3

- name: Run tfsec

       uses: aquasecurity/tfsec-sarif-action@v0.1.0

       with:

         sarif_file: tfsec.sarif        

- name: Upload SARIF file

       uses: github/codeql-action/upload-sarif@v2

       with:

         # Path to SARIF file relative to the root of the repository

         sarif_file: tfsec.sarif 

Previously, security checks would happen late in the product development lifecycle, placing a burden on engineers to fix problems long after they thought they were finished writing code. This was because our security products were largely focused on security professionals, not software developers. To make matters worse, we saw so many false positives that developers were tempted to ignore security notifications altogether.

Now, GitHub allows us to consistently automate our security and compliance, and provide immediate feedback to developers. GitHub Advanced Security has made it easy to spot compliance issues and vulnerabilities both in our own code and in dependencies early in the Software Development Lifecycle. In addition, interacting with a single portal through the lifecycle has reduced context switching and toil for developers and now enables teams to remediate these vulnerabilities quickly through automatically generated pull requests. And we’ve seen fewer false positives than expected—previously we did not even have the ability to measure vulnerabilities in dependencies consistently.

The key for this shift-left was for us to start thinking about security as a product KPMG’s security team delivered to developers, rather than a series of tasks to be conducted after code has already been integrated.

Takeaways:

• To reduce friction between developers and security, think of security and compliance as a product that serves developers, not just a set of policies.

• To turn security and compliance into products, embrace tools like GitHub Actions and GitHub Advanced Security that make compliance automatic, where possible, and surface issues early in the process when they’re easier to fix.

Apply the product mindset to everything

From the onset of KPMG Code, we made it our mission to understand the best and worst parts of the developer’s jobs. Our aim was to provide engineers with the best internal products to increase effectiveness, happiness, and collaboration across member firms. As a result of investing in developer effectiveness, innersourcing, and removing the complexity of dealing with security issues, we were successful.

The key insight underpinning all of this is the product mindset. You can apply this everywhere in your engineering organization, not just to AppSec and innersource. Stop thinking of policy as a set of static documents but rather as products that automate critical yet tedious parts of developers’ jobs. You’ll enable your developers to focus on the creative parts of coding, even as you create standards and automated processes that bring more traditional manufacturing efficiencies into play. 

For more engineering content, check out the KPMG Engineering Medium space.