Version control is critical for addressing IT governance, risk, and compliance (GRC). Monitoring your change history and having proper documentation and tracking across versions allows you to keep your data safe,improve risk management, and easily perform audits.
Follow along or jump ahead to the section that interests you the most.
IT Governance and Version Control
Insufficient version control processes can create system failures and disrupt business operations. And mistakes have serious consequences. For instance, a developer could deploy the wrong version into production — or worse, into a hardware device. This could damage finances, reputations, or even lives and property.
Not to mention these processes can open the door for cyberattacks. Security breaches — resulting in stolen source code, data corruption, or ransomware — of course, come at a high cost.
Beyond legal requirements, implementing governance and control practices is a solid business requirement. Every organization can benefit from improving security and minimizing risk.
📕 Related Resource: Learn more about Sharing Accountability for Governance, Risk, and Compliance
Back to topGovernance and Control with the Right VCS
The first step towards compliance is securing your VCS. For most version control systems, this means implementing firewalls. With a VCS deployed in a cloud — like Amazon Web Services (AWS) — you control access via security groups and access control lists (ACLs).
Firewalls and cloud settings are essential. The question is, can your VCS be made to enhance governance and control to satisfy auditing requirements? Can it make life easier for your admins and business professionals?
All version control systems are not equal when it comes to addressing these needs. Some that are very popular with developers fall short on their ability to support these enterprise requirements.
Back to topIT Governance with Git
Git is one of the most popular systems for version control. Developers typically download product source code to their machines to modify it. But using Git means developers must download entire repositories with full history. This may be a security concern for any company, especially if they are looking to audit and maintain compliance.
Break Up Your Repos
If you plan on using Git, the recommendation to improve auditability and compliance is to break up projects/products into many repos. Then you can assign permissions only to the repos containing the specific files developers are working on. This will make it easier to audit, but you will still have challenges achieving the transparency needed to satisfy all requirements. The cost of this approach is that cross-repository dependencies make it harder to develop, manage, and build your systems.
Use a Central Server
Although Git is a distributed version control system (DVCS), you are going to need a central server to secure your intellectual property (IP). There is no magical way to secure everyone’s workstation effectively. Even implementing Machiavellian technologies — like making developers work on VDI (desktop virtualization) — will only go so far in minimizing your risk.
Lock Down Your Pipeline
To secure build machines using Git for Continuous Integration/Continuous Delivery (CI/CD), you can set up firewalls or cloud-based security settings, like those described above. Those machines would logically sit next to the Git server. Their dedicated network access paths would need to be locked down. But setting all of this up and managing it in production, although necessary, can be time-consuming for administrators.
Back to topSet Up Security to Improve Risk Management
A good way to approach VCS security is to study the concept of defense in depth. You are going to need to employ multiple layers of security controls throughout your network and systems. This provides redundancy in the event that a particular security control fails or a vulnerability is exploited. Security controls can be implemented on the personnel, procedural, technical, and physical level.
Helix Core — version control from Perforce — gives administrators many granular ways to control access to code and non-code assets for compliance and governance. Let’s review some of the security layers you can set up with Helix Core.
Intellectual Property Assets Governance and Control
In a large organization with many developers, you should establish appropriate naming conventions and hierarchy design across your code repositories. This yields one of the most productive and cost-saving benefits to large development organizations, especially if code is shared across teams.
Establishing a naming convention in Helix Core will help when deciding to restrict and/or grant permissions. Permissions can be refined down to the individual file level if required.
This has an impact on GRC because, as we know, not all code should be shared. It also helps with administrative overhead. Admins and security teams can easily see who has access to what assets and assign access to new users. If there is a problem or a mistake, they do not have to run around playing detective to see what created the issue.
Back to topSimplify metadata collection and naming conventions to help meet auditing needs. It improves your security and streamlines work for your admins.
How to Refine Permissions and Policies for Users
When implementing security policies, review who can access what in your VCS. Understanding what users can see and do helps determine what permissions are necessary for IT governance. Using the principle of least privilege (PoLP), only grant access to the data and processes necessary for people and programs to complete their work.
There are a couple of ways to do this:
- Use transport layer security (TLS, the newer version of SSL) to secure communication over an internal/external network between servers, machines, and applications.
- Require users to be authenticated via AD/LDAP/MFA.
- Lock down version control servers to prevent internal tampering.
Helix Core can take your security a step further. The P4 protections table can help you refine access rights for users, groups, and programs. You can define permission levels by:
Access Level | Define users access level such as list, read, write, admin, or super user. |
User / Group | Define whether the permission applies to a single user, or a group of users (groups is recommended). |
Host | Define the specific TCP/IP address — either an individual IPv4 or IPv6 address, a range in CIDR notation, or use wildcards. This allows different permissions to be granted when accessing the server from the LAN or WAN, for example. |
Files | Define a folder tree or even specific file to which the access applies (powerful wildcards available). |
For example:
Secure Your DevOps Pipeline for GRC
You can also secure your DevOps pipelines using Helix Core. When using Jenkins or other CI/CD automation tools, you should strictly control access to the build server. Make sure to regulate access between the build server and the version control system server. Isolating the servers helps ensure that intruders won’t get in. Just as important, it also prevents them from using those servers as a jumping off point to other resources.
When refining access for these programs/accounts:
- Ensure build machine accounts are non-login, which disables anyone else from logging into the account.
- Use multiple accounts for permission delegation, instead of just granting some programs “administrative access.”
- Control access and traffic using subnets. This isolates automated processes in a subnet so they won’t have access to the entire network.
- Check how often clients and programs connect and rotate TLS tickets on a regular basis.
IT Governance and Version Control
Use Helix Core to secure all your digital assets IT governance and compliance.