![](\"https:\/\/www.trendmicro.com\/content\/dam\/article-large-tile.jpg\")
<\/p>\n<\/p>\n
<\/div>\nVulnerabilities in software and infrastructure are a fact of life for developers and SREs, but that doesn\u2019t mean you must accept them.<\/p>\n
Given the exponential growth of vulnerabilities<\/a>, DevOps teams must be aware of and learn how to mitigate these risks to ensure healthy systems and applications.<\/p>\n This article will focus on five common vulnerabilities in no particular order of severity. We\u2019ll examine some in-depth information on each vulnerability\u2019s root cause and how it can impact affected services. Then, we\u2019ll explore how to spot these vulnerabilities and outline basic strategies for remediation.<\/p>\n 1. Inherited Vulnerabilities<\/span><\/p>\n Modern software often relies on various third-party libraries and code (frequently open source) to create applications. In some cases, these components contain vulnerabilities that applications inherit. About 80% of codebases<\/a> rely upon open-source code or libraries. As a result, inheritance is one of the biggest threats for developers and DevOps teams.<\/p>\n Vulnerabilities can vary depending on the development language and framework. Therefore, consider any relevant factors before deciding on a particular language. Some languages might have fewer code vulnerabilities but rely on many more libraries, which can greatly expand their risk. Furthermore, many libraries often depend on other libraries and such dependencies are not always easy to detect or control.<\/p>\n You explicitly reference direct dependencies in your project (such as NuGet package configuration for .NET and POM.XML for Maven) so you can typically control them. However, your direct dependencies may rely on transitive dependencies, which include any packages indirectly pulled into your project by way of the directly included packages. Transitive dependencies are far less under your control and pose significant risk to exposing your application to unforeseen vulnerabilities.<\/p>\n One basic mitigation tactic is to employ automated vulnerability scanning<\/span><\/a>, such as software composition analysis, which helps detect and remediate known vulnerabilities within direct and transitive dependencies.<\/p>\n 2. Software Supply Chain Vulnerabilities<\/span><\/p>\n Within modern software development, it has become standard practice to source core components from a software supply chain. The software supply chain is the end-to-end collection of components that enables you to write and publish software.<\/p>\n This chain begins with source control repositories, code, packages, and other dependencies. Then, the chain continues as you make your application available (for example, a mobile app downloadable from an app store or open-source repository on GitHub or Docker Hub).<\/p>\n The supply chain stack\u2019s complexity \u2014 and more importantly, the lack of control over every part in that stack \u2014 can represent a significant risk. Common attack vectors include typosquatting and dependency confusion.<\/p>\n Typosquatting uses the name of an existing, often popular package to scam developers. The attacker provides a malicious version of a package or application with a similar name, hoping developers will mistakenly use it.<\/p>\n Similarly, another type of software supply chain attack that leverages package naming conventions is a dependency confusion attack. In essence, the attack relies on confusing the software installer script to download a malicious package with the same name as the intended internally hosted package. The attack opportunity is created by a misconfiguration allowing the installer to query public repositories such as npm or PIP for the dependency package, rather than only internal repositories. An attacker will attempt to exploit this by publishing a malicious file of the same name, with a higher version number, since the installer will default to downloading the latest version.<\/p>\n You can spot and mitigate this kind of vulnerability using an automated code-scanning and vulnerability-detection solution.<\/p>\n 3. Code Injection Vulnerabilities<\/span><\/p>\n Code injection, also called remote code execution (RCE) or remote code evaluation, occurs when a vulnerability allows a malicious actor to introduce their own code. The program typically executes this code during runtime.<\/p>\n There are many vectors for code injection, which commonly leads to data flow changes, loss of confidentiality, or application availability damage. This attack provides faulty data input in a form field, such as uploading malware as part of a generic file upload or adjusting data strings during a query.<\/p>\n SQL code injection is a popular mode of attack. Attackers target system database back ends by injecting malicious SQL query commands into vulnerable user inputs before being passed along and executed on the database. These commands typically aim to destroy database content or access other pieces of information not surfaced by regular application use, such as credit card details or additional personally identifiable information (PII).<\/p>\n PHP code injection or server-side JavaScript injection are other code injection examples. These code types run on the back-end servers instead of the client front end (typically a browser). Server-side code injection is a serious vulnerability, as it can compromise the servers running the application.<\/p>\n One method for spotting these vulnerabilities is by using a source control code scanning tool. This approach is useful during the DevOps build cycle where development occurs or when running the pipeline\u2019s build or continuous integration (CI) stage. However, if your workloads are already running, consider using a web application firewall (WAF) solution with integrated code injection vulnerabilities detection and\/or a RASP solution to provide additional protection against exploits.<\/p>\n 4. Permission and Access Vulnerabilities<\/span><\/p>\n The most significant vulnerability occurs when all of the application\u2019s stack components are weak. As such, overall systems and applications permissions and access are next on our list of vulnerabilities.<\/p>\n It\u2019s best to tightly regulate access to systems and permissions for performing specific actions. The more administrative access rights developers and DevOps team members have, the larger the vulnerable attack surface.<\/p>\n The concept of \u201cleast privilege,\u201d enabled through role-based access control (RBAC) or AWS Identity and Access Management (IAM), has become a must in today\u2019s software lifecycle. It follows this cycle from development, through testing, and finally to deployment and management. While it is beneficial to apply the principle of least privilege throughout an organization, its integration should first target the company\u2019s DevOps teams. After it becomes part of the DevOps foundation, it is more easily applied to interactions across systems and services.<\/p>\n DevOps teams often build applications using microservices and serverless architectures. This approach creates a complex collection of API calls and middleware within many systems, often running outside an organization\u2019s datacenter. Limiting API permissions and the scope of possible interactions across various system components (internal, hybrid, and public) is a principal best practice for mitigating or avoiding vulnerabilities.<\/p>\n These identity services are typically already present in a cloud environment. However, they are not typically enabled by default and often cost extra to enact. Azure Active Directory Premium P1 and P2 licenses provide many identity security features, including identity protection and Azure Privileged Identity Management. You can use a third-party privilege management solution in a hybrid or on-premises setup.<\/p>\n 5. Security Configuration Error Vulnerabilities<\/span><\/p>\n Misconfigurations in infrastructure, code, or other essential services can expose significant vulnerabilities. Regardless of where your workloads run, there will always be a need for credentials and secrets like authentication keys, access keys to connect systems, APIs, and connectors.<\/p>\n For instance, front-end and middleware applications rely on connection strings for authenticating to back-end databases. Often, these credentials are hard-coded in configuration files such as web.config or appsettings.json.<\/p>\n More organizations are adopting cloud environments and shifting to infrastructure as code to deploy them. As a result, deployment mechanisms such as AWS CloudFormation and Azure ARM templates, or overall Terraform deployment scripts are susceptible to storing secrets.<\/p>\n When you store those deployment files in public repositories such as GitHub, they can potentially compromise your organization. Even private repositories should not contain any secrets or credentials, as there is always a chance that an individual or process is attempting to steal them.<\/p>\n You can store those credentials in vault solutions such as Azure Key Vault or Terraform Vault to mitigate this risk. Then, you can use source code vulnerability scanning tools capable of detecting such credentials as part of your DevOps team\u2019s arsenal of detection and mitigation tools.<\/p>\n Conclusion<\/span><\/p>\n While this list of software and system vulnerabilities is far from comprehensive, these are five of the most common threats and vulnerabilities your DevOps team should try to detect and mitigate.<\/p>\n Relying on open-source packages to develop applications adds a potential security risk. Also, adopting the cloud and deploying massive infrastructure as code projects increases your possible attack surface.<\/p>\n Despite these risks, source code vulnerability scanning tools can help DevOps teams detect and protect against these vulnerabilities as you enjoy the speed, repeatability, and other benefits of modern software development and deployment.<\/p>\n For more insights into best practices for application security and open source code, check out our infographic<\/span><\/a>.<\/p>\n