By Amit Hofree, Technical Product Lead, Legit Security, shortlistee of The Cloud Awards 2022-2023 for the Security Innovation of the Year (Enterprise) category
In recent years, there has been a significant shift towards modern development methodologies and practices in software engineering. With the proliferation of cloud computing, mobile devices, and the Internet of Things (IoT), the demands on secure software systems have also increased dramatically. As a result, developers are under pressure to deliver both secure and reliable applications at a faster pace than ever before.
Many new technologies and techniques have been introduced to help organizations build and deploy applications more efficiently. However, these new approaches to increase development speed and flexibility have also introduced new challenges and threats when it comes to security. A notable example of these threats includes the rapid increase and severity of software supply chain attacks and a sprawling and vulnerable pre-production development environment.
Three Fundamental Shifts in Modern Software Development
How can we guarantee that the applications we release rapidly are also secure and reliable? To better understand the challenge of securing modern software, we’ll begin by identifying three key shifts in modern software development and explain why they pose new security challenges.
Continuous integration and delivery
With the increasing pace of development, it has become essential for organizations to be able to quickly and consistently deliver new code changes right into production environments. Continuous integration and delivery (CI/CD) practices allow developers to automatically build, test, and deploy code changes.
Why is this a Security Risk?
CI/CD systems allow developers to push new code to production automatically and at a high frequency. While this can significantly improve developers’ efficiency, malicious actors can also benefit from CI/CD pipeline automation. Because new code is being pushed constantly, organizations are forced to forego in-depth manual inspection of changes in favor of automated scanning tools and processes. These automated tools can be insecurely configured and exploited for vulnerabilities, allowing dangerous code changes to go unnoticed.
With traditional software development approaches, code changes were deployed less frequently, which gave organizations more time to review and test changes before they were released. With CI/CD, code changes are automatically built, tested, and deployed as soon as they are committed, which means significantly less time for review and testing. Additionally, CI/CD pipelines often involve the automation of many processes, including the provisioning of systems and infrastructure. As such, complex and vulnerable code patterns and vulnerabilities associated with pre-production processes and systems are less likely to be found.
The widespread adoption of cloud computing has dramatically impacted software development. Cloud platforms like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) provide developers with various tools and services that make building, deploying, and scaling applications easier.
Why is This a Security Risk?
Cloud computing means that organization-managed servers and data now live in a globally accessible location. The on-demand nature of the public cloud makes building resilient and high-scale systems easier but requires organizations to host their assets (and often their highly sensitive intellectual property) on the internet.
In the past, organizations could get an almost air-tight seal on their network protected assets. Mission-critical systems could be hosted on internal networks with highly regulated network policies and minimal external access, with changes to this configuration requiring specialized permissions. Internet-facing systems could be placed in a specialized DMZ that was heavily secured and regularly examined for potential signs of a breach. This made attackers’ lives more difficult, as reaching the organization’s crown jewels meant bypassing many lines of protection.
In the age of cloud computing, organization assets are, by definition, globally accessible. Advanced measures are employed to limit the scope of identities and their resource access in the cloud. Still, often times it isn’t easy to formulate a permissions model that is loose enough to allow efficient day-to-day work, yet secure enough to withstand attacks. In addition, cloud environments are often very complex and feature-rich, making mapping out all the organization’s assets and secure configurations very challenging.
All of this means that malicious actors with enough patience can usually find a hole to squeeze through after compromising an application. Negating this possibility requires defenders to employ a great deal of expertise and effort.
Pervasive Use of Open Source
The use of open-source software has also become increasingly common in modern software development. Open-source libraries and frameworks provide developers with access to a wide range of pre-built components that they can use to accelerate development. Additionally, the open-source model allows developers to collaborate and share knowledge more efficiently, which can help drive innovation and improve software quality.
Why is This a Security Risk?
Open-source software is often developed and maintained by a community of volunteers rather than a single vendor. This means there isn’t necessarily a process of secure development and testing in place, and there may be fewer resources dedicated to securing the project. As a result, there may be a greater risk of vulnerabilities being introduced into the code via open-source software components.
Vulnerabilities in upstream open-source code aren’t typically subject to the same security processes as in-house developed code, and may be fixed or not fixed according to the maintainers’ availability. This requires specialized tooling in order to track the existence of vulnerabilities in open-source software utilized by your organization.
Additionally, open-source software is often developed and maintained by a large, distributed community of developers, making it difficult to ascertain that every collaborator is not malicious. This opens the door for attackers to masquerade as legitimate contributors for some time to build a reputation in the project, only to sneak in a hidden vulnerability inside a seemingly innocent code contribution.
Finally, open-source software often uses other open-source software internally. When a project begins to utilize open-source software, it almost always means that it will be forced to use a vast number of open-source libraries and packages. Utilizing many open-source dependencies increases the vulnerable surface area of your application dramatically. Any vulnerability in an upstream package will also affect your application, and supply chain attacks carried out on an upstream library may also spread to your code base.
Traditional Application Security Is Not Enough
The security risks above have a common basis – they all collectively put the deployed application at an accumulated level of risk. Modern development practices facilitate a plethora of ways an application may be compromised, both in a deliberate manner or by accident.
This idea has birthed the concept of Application Security or AppSec. AppSec is the practice of ensuring the security of individual applications or software systems, as opposed to the classical approach of securing the network and the hosts on which the application is running.
An essential subject in AppSec is Application Security Testing or AST, which is the process of testing an application or software system’s security to identify and address vulnerabilities. There are many different approaches to traditional application security testing, including manual testing and automated testing, which is prevalent in CI/CD development pipelines. Some techniques used in application security testing include:
- Static testing (or SAST): This involves analyzing the source code of an application to identify potential vulnerabilities.
- Dynamic testing (or DAST): This involves running the application and testing it in real time to identify vulnerabilities.
- Dependency scanning (or SCA): This involves determining the application’s dependencies and checking if any of them are affected by a publicly known vulnerability.
While implementing a traditional AppSec program can significantly boost an organization’s ability to protect itself, more is needed to guarantee a modern application is indeed safe. The mere existence of such a program can give organizations a false sense of security. Here are some of the main reasons why:
- Lack of coverage: AppSec tools are usually deployed as point solutions per application to protect against a specific type of risk to that application. This is a myopic approach that can provide a false sense of security. Without an organization-encompassing way to view an AppSec tool’s coverage, it can be easy to miss critical risk points. For example, an application may be protected with SCA scanning to defend itself against upstream vulnerabilities in open-source components. This application can also depend on an internal package not scanned by the SCA tool, which may rely on vulnerable open-source packages, thus exposing the “protected” application to these vulnerabilities.
- Lack of context: AppSec tools are often deployed with basic permissions and are limited to viewing only the application’s source code or compiled form. As a result, the priority they assign to issues is very one-dimensional, without considering many characteristics of the application, such as where it is deployed, whether it is internet-facing, whether it is a business-critical application, and more. Remediation and triage decisions are consequently difficult to prioritize. For example, after integrating SAST scanning, organizations are often times swamped with high-severity findings. They start remediating them randomly, possibly neglecting issues affecting business-critical applications.
- Lack of visibility: AppSec tools are designed to protect an application from a particular type of risk optimally. However, it is up to the organization to decide which tools to incorporate where, and this can pose a challenge as software development environments tend to be very complex and encompass multiple systems. Because environments can always be hacked through their weakest point, an AppSec program must include every type of risk relevant to the application. It must diligently map these risks to the appropriate tools.
The Bigger Picture: Software Supply Chain Security
The gaps mentioned above require a paradigm shift in how we approach modern AppSec. The problem of securing an application needs to be approached holistically by mapping out all the possible attack surfaces for the application, carefully weighing their level of risk to prioritize them, and remediating them one by one. All the while constantly tracking remediation progress and reevaluating the current risk state.
These capabilities are taking shape in the emerging category of Software Supply Chain Security solutions. In Software Supply Chain Security, the entire pre-production development process of an application is examined and secured, as every step in this process may be exploited to compromise an application. A good supply chain security program should cover all the development systems from code to cloud and implement controls to manage risk in every step of the SDLC.
Several high-profile software supply chain cyber security incidents have occurred in recent years. For example, the SolarWinds hack in 2020, in which a state-sponsored hacking group infiltrated the software supply chain of the popular IT management software, affected thousands of organizations worldwide. Another example is the NotPetya attack in 2017, in which ransomware was spread through a Ukrainian software company, causing widespread damage to businesses across Europe and Asia. These incidents, which involved the insertion of malware into the software supply chain, highlighted these new types of vulnerabilities of software applications to attacks from malicious actors.
It’s worth noting that software supply chain attacks and threats are evolving rapidly compared to traditional AppSec. While AppSec has a range of tools and practices available to secure application code, but software supply chain security has fewer options. This is partly due to the greater complexity of securing the software supply chain, as well as the fact that it is a relatively new category of cyber security solution with a fewer number of security vendors and platforms.
Additionally, supply chain security often requires collaboration and coordination between different organizations, which can take considerable time and effort. Fortunately, the incorporation of supply chain security solutions into traditional AppSec programs is increasing rapidly as organizations become aware of the need to secure the supply chain and invest in these tools and best practices.
To help you jumpstart a supply chain security program for your organization, I’ll present some common subjects you can start addressing today.
Modern pre-production development processes and systems are complex and feature-rich, and insecure configuration of these systems must be avoided. Ensuring secure configuration will make it much harder to compromise your software, but these efforts can come at the price of making life slightly harder for your developers. It’s vital for organizations to ensure that their development systems are configured to balance security and velocity for your organization optimally.
For example, allowing anonymous login to a self-hosted development system is almost always a wrong choice but is still permitted by some organizations. On the other hand, requiring two-person code review for every commit is sometimes perceived as too much of a slow-down to be considered but enhances security greatly.
User Least Privilege
In the context of the software development life cycle (SDLC), user least privilege refers to the principle of giving individuals and teams involved in the software development process only the minimum level of access and permissions necessary to perform their intended tasks. This is a critical security principle because it limits the potential damage that can be done by malicious actors who may gain access to the development environment.
For example, developers should only have access to the source code and tools they need to perform their job, and should only have access to sensitive data or production systems when absolutely necessary.
Implementing least privilege for collaborators in the SDLC requires access control mechanisms such as role-based access control (RBAC) that are usually built into SDLC systems and can be configured by an administrator. It also involves regularly reviewing and revoking access for individuals and teams who no longer need it, and implementing strong authentication and authorization mechanisms to prevent account takeover attacks.
Secrets in code
Secrets in code refer to sensitive information, such as passwords, keys, and tokens, that are embedded in the source code of a software application. These secrets are often used to authenticate or authorize access to external systems, such as databases, APIs, and cloud services. Because these secrets are stored in the source code, they are typically committed to version control systems and may be accessible to multiple individuals involved in the software development process.
Secrets in code can pose a significant security risk because they can be accidentally leaked or intentionally stolen by malicious actors to gain unauthorized access to sensitive data or systems.
For example, an AWS access key embedded in the code to allow an application to authenticate to AWS services may be found by a malicious actor and utilized to compromise the AWS environment.
In order to mitigate this risk, it is crucial to use secure methods of storing and distributing secrets, such as utilizing secret management tools and avoiding hardcoding secrets in the code. Additionally, it’s important to have a good governance and monitoring system in place, to ensure secrets are not leaked or shared with unauthorized parties and to track any suspicious activity.
Summary: Embracing a Holistic Approach with Supply Chain Security
The software development landscape is constantly evolving and becoming increasingly complex. Because of this, organizations must take a holistic approach to secure their applications. Traditional application security solutions are no longer sufficient in protecting against these modern threats. Supply chain security offers a more effective way forward by focusing on securing the entire software development process.
By implementing supply chain security, organizations can:
- Better protect their applications
- Reduce risk exposure
- Ensure compliance with regulations.
The examples described above can be a good starting point for an effective supply chain security program, and security solutions from vendors like Legit Security can accelerate the adoption and implementation of these best practices and many others. Together with a traditional AppSec program, a more holistic approach to software supply chain security can help ensure your software is safe and secure for years to come.