In the world of software development, source code is computer code that is written in an original programming language before being compiled into object code. In the world of DevOps, the source code is typically infrastructure-as-code that can create local or cloud computing resources on demand. Source code is created for some form of software application and is typically managed by a team of developers.
Source code is a valuable asset to any business for many reasons – proprietary custom code is written in-house and often takes years to develop. Many modern digital businesses are founded on a patented application that has been developed for a specific purpose, perhaps it is packaged and sold to customers like Windows 11, or its source code that unpins the technology of the business such as Netflix streaming technology.
Businesses use source code as the building blocks of their entire cloud environments. On-premises and cloud-based infrastructure is being developed in code and it’s the source code that provides the source of truth for an entire business’s configuration.
As business transformation initiatives continue to gather momentum and more organizations start to invest in DevOps-centric working environments, several safeguarding measures are needed to uphold DevOps security and to protect valuable source code.
Cybercriminals are Stealing Source Code
Source code is only as secure as the systems in place that protect it. Developers must embed security best practices when writing code throughout the development cycle. These days software is nearly always written and maintained inside a code repository that uses the Git version control system.
Git version control software can either be hosted on-premises or in the cloud, and either a private repository or a public one. Tools such as GitLab, BitBucket, GitHub, and other similar services are commonly used to store source code in a secure and encrypted source code repository. Protecting source code repositories should be a fundamental requirement in any security-conscious business.
Source code exposure does happen. Case in point, a major bug was recently discovered in the Microsoft Azure App Service that was not discovered in over 4 years. It was identified that the Azure App Service was embedded with an insecure default behavoir for any source code written in PHP, Python, Ruby, or NodeJS and was deployed using the Local Git of the Azure App Service.
Local Git is an optional CI/CD deployment tool that enables code to be pushed directly to an Azure App Service instance so code is executed serverless. With this approach, the code was written to a public folder located at /home/site/wwwroot/ on the Azure App instance. Microsoft knew this issue and as a workaround used an XML-based web.config file to locally manage settings on the instance.
This approach worked perfectly for customers using Microsoft IIS, C#, or ASP.NET as a web server, but unfortunately PHP, Python, Ruby, and NodeJS do not recognize web.config files resulting in the local security settings being bypassed. On the instance, the /.git folder and all the source code contained within could be accessed publicly.
Another major incident of source code exposure affected the online streaming platform Twitch, a service that is popular with gamers. Due to a configuration error over 6000 git source code repositories were exposed to the public internet and the leak contained the earning details of some of the most popular streamers breaching numerous privacy laws in the process.
Source Code Security Risks
The loss of source code is embarrassing for any business and it will likely lead to a loss of confidence in the offender’s ability to protect company R&D. However there are several risks attached to source code leaks and these risks are significantly greater if the business does not adhere to security best practices.
The biggest threat to source code is the incorrect handling of secrets. Secrets include elements such as username and passwords, API Keys, credentials for cloud providers, database connection strings, and so on. When data from Twitch was exposed, some 1100 incidents were identified as secrets being exposed. A secret on its own may have very little impact if lost, however, thousands of secrets exposed makes the attack surface of any business vulnerable.
Human error is the main cause of source code security risk, combined with lack of product knowledge or lesser skilled junior workers who are let loose on production code. Everyone makes mistakes, and when coding it’s all too easy for a developer to hard code a secret to test if the relevant code works, and then forget to remove the secret.
Protecting the Entire DevOps Pipeline
Education plays a major role in workplace security as teams should be briefed on what the expected security standards are and all code should be peer-reviewed for completeness by a review panel that includes senior developers and representatives from the security teams. But what else can be done to secure the development process and reduce the risk of source code exposure?
- Secure Development is Everyone’s Concern: Security is best realized when every team works together to achieve an end goal. This includes creating and adhering to standards throughout the business. This approach is a huge challenge and often requires an in-house cultural change.
- Write Clean and Manageable Code: Although challenging, writing code to predefined standards and making code reusable is essential to improve security. Code should have nothing hardcoded such as variables and it must be documented inside the code layout. A readme can be automatically generated so it should be the minimum standard.
- Protect Your Code Repository: The repo should be protected by multi-factor authentication with permission-based user credentials following the principle of least privilege. Code should be peer-reviewed for security standards before being merged.
- Protect Your Secrets: Source code often requires sensitive information such as login keys, root values, system parameters, and so on. Separate your secrets from the code and save them to an encrypted secrets manager, upload parameter values to a parameter store, and never hardcode variables into the code.
- Look for Vulnerabilities: Scan source code for vulnerabilities, scan the open-source libraries to look for license allowance or outdated OSS versions
It is also possible to deploy third-party security solutions to counter the new challenges and risks of modern coding. Security tools can be embedded into the entire DevOps life cycle – this approach is often known as DevSecOps and its purpose is to protect applications even if legacy, microservices, or serverless within a single platform.
A WAF (Web Application Firewall) should sit in front of all developer tools, as it not only protects inbound and outbound workloads but can also patch security and any vulnerability almost instantly. DevOps Tools usually require generous permissions and the WAF adds an extra layer of protection.
The DevOps pipeline is reliant on API interactions; third party tools can protect each API request protecting the application as soon as it’s published. If you are publishing serverless applications or apps directly onto a cloud engine, consider investing in a RASP solution (Runtime Application Self-Protection) – RASP is built into the serverless application and runs natively giving developers extensive monitoring and scanning capabilities of the app, plus several tools to automatically protect the app.
Alton Clarke was born and raised in Syracuse. He has written for MSNBC, The Business Insider and Passport Magazine. In regards to academics, Alton earned a degree from St. John’s University. Alton covers entertainment and culture stories here at Diving daily.
