Protect Your Source Code With Cloud Development Environments
Debo Ray•Rob Fletcher•
Why is protecting source code and company IP important?
When considering security breaches, we typically think about the exposure of private user data. But as of late, we’re continuing to see a trend indicating that source code is an equally-lucrative target for hackers:
"For CISOs, the incident demonstrates that your source code repositories is no less a target than your customer data, as it can reveal valuable information about your application’s underlying architecture.” - Tim Keary on the recent LastPass breach (VentureBeat)
In addition to risking proprietary algorithms, trade secrets and intellectual property, the theft of source code allows attackers to discover security vulnerabilities that they can expose to further compromise a system:
- With direct access to a system’s code, attackers are able to identify and leverage previously-unknown vulnerabilities (or even known vulnerabilities) in a service or application.
- Source code repositories may contains secrets/credentials that would allow an attacker privileged access to sensitive data.
Companies that are primarily built around open source aren’t out of the weeds either. While various security tools are built into GitHub (oftentime integrated into the code review phase) for the externally-facing software, a lot of the private source code repositories that serve the enterprise offering usually doesn’t undergo the same rigor.
From a security functionality perspective, source code security can be accomplished via various permutations of the following:
- Data security: Not only does this function work towards securing datastores (store for various types of PII) from a data breach standpoint, but also access controls and auditing around source code access. Access controls help reduce the surface area of risk, while auditing capabilities allow for investigations in cases of data breaches.
- Employee access and general Identity and Access Management (IAM): Depending on the function, various teams need access to different tools. Without the ability to enable appropriate access controls, the easiest way to “move fast” is by giving access to everyone. Till the inevitable data breach or security incident. Without strong audit logs, mitigating and remediating an incident becomes quite hard. Themes of this can be seen in the Sept 2022 Uber hack, when the adversary claimed to have access to Uber’s proprietary source code and infrastructure configuration.
Now, security measures introduced haphazardly can introduce significant friction in the software development lifecycle. Having a large security backlog is a reflection of security having been introduced too late in the software development lifecycle (SDLC), thus stifling development teams who now have the added burden of balancing between product updates and patching security vulnerabilities. This is where the fairly new specialization of DevSecOps comes in, a more security-focused incarnation of the DevOps role.
DevSecOps
In modern software development companies, having a strong security posture and applying security best practices is a differentiating advantage. No more is it just about financial losses from a security or data breach – apart from increased regulatory scrutiny, these incidents also decrease customers’ trust and negatively impact a company’s reputation.
We realize that reactive security measures do not cut it any more - so how can we enable our development teams to build secure products instead of trying to find a balance between finding a balance between constantly fixing security issues vs building amazing products. The goal of DevSecOps is to integrate security tooling into the SDLC to enable just-in-time remediation of security risks. A few examples:
- Developers aren’t malicious, but everyone makes mistakes. As a developer, the earliest you are made aware that you’re about to introduce a security regression, the easier it is to fix. This is where a basic IDE (integrated development environment) extension
- Analysis tools: SAST and DAST tools are the talk of the town and critical to secure code development practices, but they are often quite hard to integrate. Neither do we want a developer to jump through extra checkboxes when all they want to do is check in a flashy new feature, nor do we want to introduce potential latencies in the production environment.
- Heterogeneity presents more challenges: previously, security tools prioritized on Python or Node.js over other languages. But with infrastructure configuration being stored as code, and the influx of a large number of frameworks and tools, getting security coverage over the ever-growing attack surface is continually expanding problem-space.
Challenges of DevSecOps
Companies are complex, every organization has their own flavor of the SDLC and general development processes. There are various security tools - how to get them integrated effectively to get the maximum security outcomes while minimizing end developer impact?
Performance regressions: Being able to test the impact of introducing a new tools is another hurdle for the DevSecOps engineer to jump over! Is the “git commit” action now taking longer, or did I just introduce further latencies in CI, or even worse, since everyone is complaining about this new tool I rolled out, should I just put this in “observe-only” mode and we can deal with the tickets later?!
With cloud-based software development environments, we can dramatically reduce the risk of source code attacks by:
- Not storing source code directly on developer computers: when a developer uses cloud-based environments, the codebase never stored on their machine; common attack paths (e.g phishing, malware) no longer provide direct access to code and, as a result, are far less likely to succeed. Even if social engineering attacks inadvertantly give access to source code (potentially exposing known or unknown security flaws), centralized development workflows paired with audit logs reduce mitigation times, and aid in containing the blast radius of the breach.
- Requiring enterprise-level authentication: we can drastically decrease the attack surface for a developer’s laptop by providing tighter access control to remote development environments; e.g. by enforcing 2FA and minimizing session duration, we shorten the exposure window that would-be attackers have access to source code.
- Allow centralized rollout and metrics-driven monitoring of new cybersecurity tools: we all want to shift security to the leftmost stages of the SDLC, but rolling out tooling from various providers to the appropriate stage, is strife with challenges. Targeting and collecting metrics from small clusters of software development teams or environments is almost impossible, fundamentally impacting efficiency.
Conclusion
Centralized, cloud-based environments not only help developers be more productive, but also operate in environments that help them be secure by default. In all transparency, these tools don’t help with insider threats as is, but it will make it easier for security teams to apply policies and roll out tooling (eg: tooling to prevent introduction of malicious code, help with supply chain attacks, data loss and general application security testing etc) in a centralized manner.
In summary, cloud-based environments offer a way to have secure development by adding a meaningful buffer between an individual developer’s laptop and their company’s proprietary source code, drastically helping security teams reduce the overall vulnerability of a company in the case of increasingly-popular source code attacks.
Debo Ray
Co-Founder, CEO
Rob Fletcher
Co-Founder, COO