avatarTeri Radichel

Summary

The article discusses the merits and considerations of using AWS Code Commit in conjunction with GitHub for source code control, emphasizing the importance of security, network control, and the potential benefits of using multiple cloud providers for redundancy and diverse feature sets.

Abstract

The author, Teri Radichel, reflects on the use of AWS Code Commit and GitHub as complementary tools in source code management, highlighting the advantages of each service. Radichel advocates for a dual-repository approach to enhance security and redundancy, noting that while GitHub offers robust security features and a user-friendly interface, AWS Code Commit provides private networking capabilities and granular access control through AWS IAM. The article also touches on the importance of evaluating the security of both services, considering insider threats, log integrity, and the ability to operate in a private network. Radichel emphasizes the need for strategic code scanning practices and the enforcement of Multi-Factor Authentication (MFA) when checking in code. The discussion extends to the risks associated with relying on a single cloud provider and the potential for ransomware attacks, advocating for a best-of-both-worlds strategy to leverage different code scanning solutions and security features offered by AWS and GitHub.

Opinions

  • The author prefers using both AWS Code Commit and GitHub to leverage the strengths of each platform, such as GitHub's security features and AWS Code Commit's private networking capabilities.
  • Radichel suggests that a single set of credentials for both repositories could be a security risk and advocates for a pull model with multiple sets of credentials to mitigate this.
  • The article expresses a preference for managed source control services over self-hosted solutions due to the complexity and lack of enjoyment in managing such systems.
  • The author values the ability to control networks that access each service and prefers options that allow for operation in a private network to reduce exposure to vulnerabilities like Log4J.
  • Radichel points out potential security weaknesses in GitHub Actions and GitHub Secrets, emphasizing the importance of securing logs and ensuring log integrity.
  • The author recommends strategic placement of code scanning to balance security with developer productivity, suggesting that scanning should not occur on every single code commit.
  • Radichel is currently working on enforcing MFA when checking in code via a script, indicating a commitment to continuous improvement of security practices.
  • The article advises readers to perform a proper assessment of any code repository they use and to follow best security practices, regardless of the platform chosen.

AWS Code Commit vs. GitHub — Why Not Both?

ACM.259 Architecting a source code control solution

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Application Security | Secure Code | AWS Security | GitHub

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I added a function to check code into GitHub into my code base.

I’ve also written about how I am going to try to push code from GitHub to AWS Code Commit and leverage events in AWS Code Commit to publish web sites. But why? Isn’t one or the other good enough? Sure, probably. Especially if you host it yourself and follow all the security best practices and keep your repository off the Internet in a private network.

In this post I’m going to ponder AWS Code Commit vs. GitHub and what I like about each of them. Remember that you can schedule a consulting call with me through IANS Research. This was a question I got recently.

I generally don’t recommend or tell people what product to buy on calls. But I will recommend how to evaluate products and in some cases mention pros and cons of different options if I have direct experience with the product. The problem is generally people come to me with a list of products and want to know which one to buy. No one has used every product out there and if they have it’s probably hearsay and not direct experience using every product. But in this case we are going to use two different products — and I do have a lot of experience with source control and deployment systems like:

  • GitHub
  • Subversion
  • Perforce
  • CVS (Concurrent Version System) and some variations
  • AccuRev
  • Microsoft Visual Source Safe
  • GitLab (analysis)
  • Azure DevOps (analysis)

So coming from this background I can tell you what I like and do not like about various source control systems and potential security risks. One of the most interesting source control systems I used which I don’t think is as widely known is AccurRev. I like the way it handled branches and merging better than some of the more popular options. I actually use different repositories to emulate how it works to some degree.

I really like some of the security features GitHub has to offer. I’ve written about some of those in prior posts and will probably cover some others in upcoming posts.

I’ve also written about how to secure your network if you’re using a hosted version of GitHub, and it’s not ideal. There’s no way to set up a PrivateLink with AWS at the time of this writing to keep things off the Internet, but there are some steps you can take to lock down your network to specific IP addresses. There’s no option for leveraging a VPN to tunnel all your traffic through it, should you want to do so.

It would be better to host your own GitHub instance and GitHub Actions runners if you want to have control over the networking, identities, and data security. But that comes with it’s own set of challenges. A hosted solution is nice — especially for startups and small companies who do not have a lot of resources.

I never again want to host my own source control system. It’s not fun and I remember musing at one point when I hosted my systems in a rack in a data center that if someone could create a hosted solution for the servers and development systems so developers could just focus on writing code they would be rich. (Think AWS, GitHub, etc.) But I didn’t want to do it. I don’t like managing that stuff. But I do want secure options for storing my code and triggering events.

One of the benefits of AWS Code Commit is that it allows you to keep your source control system on a private network, and yet it is still a managed service. You can control the networking and grant granular access through IAM roles and policies.

One of the questions you need to ask yourself is — who do you trust more with your code? Have you performed a security assessment of both options? Have you looked at how many times either option has been in the news with some kind of vulnerability or breach?

Have you explored how well each company keeps insiders out of your proprietary code? Is that information available and have you reviewed it? If an insider can see your code they may be able to find and exploit vulnerabilities, in addition to stealing your intellectual property (IP).

How can you control the networks that can access each service? Can you run the system in a private network so in the case of a vulnerability in your code or that of the cloud service your system is not exposed to the Internet? I mentioned how Log4J would be thwarted in that case in a prior post.

And by the way, if you are using Azure DevOps that is one of the main reasons I opted not to. The policies are very intriguing. I really liked some of the options Azure DevOps provides in terms of creating policies in your deployment processes. The problem was the network requirements and domains you need to allow to use the service were quite extensive last time I checked. Oh, let’s just use a proxy you say? That way we can operate in a private network and only open a firewall rule to the proxy. What’s on the other side of the proxy? Have you checked? (Hint: It’s probably wide open.)

What sort of logs can you obtain for each service? Who has access to the logs? How timely are the logs? Can you secure the logs and ensure log integrity? Take a look at some of the caveats I wrote about in terms of logging for GitHub Actions when using GitHub Secrets. Where might your secrets be logged in any source control system you use?

I remember looking at the output of AWS UserData in the console when you looked at a screen shot of an EC2 instance and there were the credentials for the Capital One Chef system for anyone to see. This was in a dev environment but anyone who had access to production, as I did, would be able to see the same. I wrote about the problem on the company blog because it was the best way to get visibility for a problem and get it fixed at the time. Someone commented “This is gold.” Hopefully it was someone on the penetration test or red team not someone with malicious intentions. AWS has since resolved that problem because you can no longer see the logs during the cloud init process. You can also use AWS Secrets Manager and make sure you don’t log those secrets!

How is your source code secured within the system — with your own encryption key that you control and write policies for or a key that is used for multiple customer accounts?

What if the source control system is inaccessible because you can’t login? Microsoft recently had a 5-hour outage. AWS recently had a much shorter one and from my standpoint has had less outages overall, but they can still occur.

What if ransomware gets into your source control system? Do you have a backup? How long will it take you to restore it and get working again? Can the ransomware get to your backups? This is one of the reasons I recommended a pull model rather than a push model for deployments and multiple sets of credentials where one single set of credentials does not have the “keys to your kingdom” in the last post.

And that is why you might actually want to consider two source control systems instead of just one, at two separate cloud providers. AWS CodeCommit has a way to sync to different repositories. The problem here, compared to my last solution, is that the same set of credentials pushed to both. If that single set of credentials becomes compromised you might have a bad day.

In addition, the different source control systems may offer different code scanning solutions, all of which are valuable — especially if they are free. GitHub has some free vulnerability checking which is pretty nice for public repos, for instance. For private repositories you will have to pay for the advanced security service.

You can use Code Guru with AWS Code Commit, however it “finds common problems” in Java or Python only at the time of this writing.

Of course you can integrate scanning tools into a pipeline separately from your source code as well. Different types of scans find different problems. I’ve seen some people suggest you should scan the code via a GitHub action but I’ve already written about some of the considerations if you choose to use those.

Also, you don’t necessarily want to scan every single time you commit the code. You need to be strategic about where you place your scanning to ensure that you don’t let code pass that has not been scanned while at the same time not running a lengthy scan on every single code commit. Any experienced developer will tell you the latter is not going to work out very well when you’re trying to get a project done. On the flip side letting developers decide when to run the scan also isn’t in your best interest. These are the types of problems I help customers with who schedule calls through IANS Research.

Best of both worlds — using AWS Code Commit and GitHub together

I am going to explore using GitHub and AWS Code Commit together in upcoming posts. In the past, I did something similar with GitHub and Bit Bucket. It doesn’t matter which code repository you use, as long as you have done a proper assessment and are following best security practices.

Any code repository comes with risks. You need to understand what they are and address them in your processes and architecture. You can contact the companies involved and let them know if you have any concerns with security weaknesses in the product or service. You also want to understand what options and features are available to find vulnerabilities in the code you write and integrate into your software development projects.

The one thing I am working on right now — how to enforce and prompt for MFA when checking in code via a script.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
Source Code
Revision Control
Source Control
Software
Security
Recommended from ReadMedium