devopsy.kinsta.cloud

Tag: supply chain security

Futurum Group Survey Surfaces DevSecOps Progress on Multiple Fronts

A survey of 110 security leaders finds all are investing in software supply chain security, with application security posture management (ASPM) and DevSecOps automation and orchestration topping the priority list, followed closely by security composition analysis (SCA) tools, application programming interface (API) security and dynamic application security testing (DAST) tools.

In addition, 30% of respondents expect to be piloting a software bill of materials (SBOM) initiative in the next 24 months, the survey finds.

However, the source of the funding for these initiatives is becoming more of a shared responsibility, with only 21% of respondents reporting that security budgets are the sole source. In fact, half of the respondents (50%) noted application development teams now own responsibility for application security.

Overall, only 25% of respondents said there is limited collaboration with application development teams, resulting in occasional friction, compared to 59% that said there is good collaboration with room for improvement. Only 16% said there is a tight partnership based on shared goals.

Fernando Montenegro, vice president and practice lead for cybersecurity, said it’s clear there is now more collaboration between application development and cybersecurity teams, with more security tools being incorporated into DevOps workflows. However, improving software supply chain security it’s also still very much a work in progress, he added.

The degree to which application developers might share the same level of optimism about the state of DevSecOps is less clear. Historically, many developers have resented requests to search for vulnerabilities in code that either never made it into an application running in a production environment or are only found in an application that isn’t accessible externally.

Additionally, no one is quite certain to what degree artificial intelligence (AI) is improving the quality of the code being generated versus making it worse. On the one hand, far too many application developers lack cybersecurity expertise, so much of the code they have generated has been flawed. However, general-purpose AI models have been trained using examples of flawed code randomly sourced from across the internet. Not surprisingly, large language models (LLMs) are generating code with known vulnerabilities.

Hopefully, the next generation of LLMs will be trained using examples of code that have been vetted for security flaws, which, when coupled with more advanced tools that are leveraging AI to discover vulnerabilities as code is being written, should eventually improve the overall state of application security.

Of course, it’s also safe to assume cybercriminal syndicates and various nation states are now also using AI to identify vulnerabilities in code, but also generate the code needed to exploit those vulnerabilities. As a result, the number of cybersecurity incidents involving legacy code is likely to dramatically increase in the months ahead.

DevOps teams at the very least should by now be reviewing what changes to existing DevOps workflows need to be made to achieve that goal. After all, the easiest vulnerability to fix is the one that was never created. The challenge, of course, is determining where the funding needed to acquire the tools and platforms that make it possible to build and deploy more secure applications is actually going to come from.

May 27, 2025
How to Extend an Application Security Program to AI/ML Applications
Enterprise applications that rely on large language models (LLMs) are rapidly evolving, introducing new security risks. Traditional application security, or AppSec, still plays an important role in securing AI/ML applications and ensuring responsible outputs. At the same time, there are new AI/ML application risks that will require new approaches.

AppSec measures focus on securing source code, third-party dependencies and runtime environments. For example, third-party software libraries and services such as npm, GitHub or maven repos can introduce attack risks. Developers also employ toolchains for building and packaging software that includes proprietary and third-party components. These toolchains need to be secured, as does the original business-specific logic that the enterprise develops. Applications deployed in production environments use dependent services for messaging, network gateways, storage, etc. These environments as a system, must also be protected.

To meet these security needs, AppSec teams invest in point security solutions such as SAST, DAST, SCA, Endpoint Security, RASP and Perimeter Security. These tools are supplemented by management platforms such as cloud security posture management (CSPM), application security posture management (ASPM) and cloud native application protection platform (CNAPP).

New Security Challenges for AI/ML Applications

While various AI/ML application risks are like traditional application security risks and can be protected using the same tools and platforms, runtime security for the new models requires new methods of securing the applications. 

For example, LLM models trained with proprietary data expose new data security and privacy risks. Datastores have typically been protected with role-based access control (RBAC), using the access controls to segregate confidential and proprietary information from public data. However, AI models store the data in a form that does not allow applying traditional data controls like RBAC, creating the risk of private data being included in LLM output. Instead, the business should create an additional security layer to detect and protect proprietary or personally identifiable information (PII) in the LLM responses. 

Another new risk is the possibility of model theft and denial of service (DOS) attacks on the freeform query interface used to request responses from the LLM. Preventing this requires additional security measures to validate the content and volume of queries, as well as the data that is contained in the responses.

The utilization of open-source LLM models presents risks due to the lack of provenance in their training data. These models can produce inaccurate results and can be deliberately poisoned. When combined with AI agents for automation, these inaccurate results and poisoned models can lead to significant business risks.

The Open Web Application Security Project (OWASP) offers guidance here with their OWASP Top 10 for LLM Applications. Some of the risks included on this list can be mitigated with traditional AppSec tools and platforms, while others require new LLM-specific techniques.

OWASP LLM security vulnerabilities that can be managed with existing AppSec approaches:
- Improper Output Handling: Using automated execution based on LLM output or plugins to automate based on LLM output can result in privilege escalation, remote code execution and XSS, CSRF and SSRF in browsers. Modeling threats using a zero-trust approach and using application security verification standards can mitigate this vulnerability.
- Data and Model Poisoning: Data poisoning can occur inadvertently or maliciously by providing incorrect data to pre-train, fine-tune or embed data used in the model. Validating data provenance used for training, vetting data vendors, controls for accessing only validated data sources, storing user-supplied information in vectors and not using it for training are some of the techniques that help mitigate model poisoning.
- Supply Chain Vulnerabilities: Traditional supply chains focus on code provenance, while the LLM supply chain extends the focus to models and datasets used for training. Fine-tuned models with LoRA or PEFT add to the supply chain risks. Risks include poisoned crowdsourced data or vulnerable pre-trained models, causing the model to perform with incorrect or skewed results, which becomes an advantage for threat actors. Vetting a comprehensive bill of materials, including datasets, base models, fine-tuning add-ons and licensing checks, along with red teaming testing, will mitigate the vulnerabilities. Industry should move toward automated validation and verification mechanisms to better manage supply chain risks.
- Unbounded Consumption: When an LLM allows users to conduct excessive and uncontrolled inferences, it leads to risks of model denial of service (DoS), economic loss and model theft. Rate limiting, input validation, throttling and resource allocation management are among techniques that can be used to counter vulnerability.
- Excessive Agency: The unmanaged ability to interface with other systems and take actions in response to prompts, leading to unintended consequences based on hallucinations, compromised plugins or poorly performing models. Minimizing extensions and their functionality, implementing authorization mechanisms and sanitizing inputs and outputs can mitigate excessive agency.
- System Prompt Leakage: Prompts to LLMs are not intended to be secrets as they could be stored and monitored for refining the system. Prompts could include sensitive information for a more accurate response from LLM that is not intended to be discovered. This causes the risk of exposing secrets, internal policies or disclosure of user permissions and roles. Implementing guardrails outside LLM for input validation, removal of secrets in prompts and implementing agents/plugins with least privilege to perform their tasks can mitigate risks in system prompt leakage.
LLM security vulnerabilities requiring new approaches:
- Prompt Injection: Prompt injection involves manipulating model responses through specific inputs to alter behavior. These can be direct, i.e., user input, or indirect, i.e., an external source such as a website as input. Multimodal AI may also be susceptible to cross-modal attacks. This can lead to exfiltration of private data, deletion of proprietary data or intentionally incorrect query results. Using model behavior constraint rules, input and output filtering, segregating and identifying external content and performing adversarial attack simulations can help mitigate the vulnerability.
- Sensitive Information Disclosure: Applications using LLMs risk exposing sensitive data through their output. This data can include personally identifiable information, sensitive business data or health records based on training data and input prompts. Data sanitation techniques in training data, input validation, segregating data sources, homomorphic encryption and enforcing strict access controls can mitigate disclosure of sensitive data.
- Misinformation: LLMs can seem authoritative even though they include hallucinations, and bugs in generated code can be hard to detect, causing problems downstream when LLM output is used without proper validation. There is no authoritative way to ensure the robustness of information from LLM. A combination of human oversight, education of users on limitations of LLMs and automatic validation in high-risk applications can mitigate the effects of misinformation.
- Vector and Embedding Weakness: Retrieval Augmented Generation (RAG) is a technique that enhances the contextual relevance of responses by providing additional information stored as vectors and embeddings as part of a prompt to LLM. This can lead to unauthorized access, data poisoning, data leaks or behavior alteration without proper controls on storage and usage of vector embeddings. Implementing robust data validation of inputs, permission and access controls of embeddings and validating embeddings for cross-dataset pollution can mitigate this vulnerability.
Other resources provide additional useful guidance and resources on securing AI/ML applications. The MITRE Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS) is based on real-world attack observations and can be mapped back to many of the techniques for exploiting the vulnerabilities that are detailed in the OWASP Top 10. These are complemented by new projects such as Garak, an open-source effort to provide a comprehensive security posture for AI applications.

Conclusion

Extending an AppSec program to AI/ML applications involves adapting and enhancing traditional practices while addressing new challenges related to AI systems. By building on proven methods and integrating AI-specific security measures, enterprises can confidently secure their AI/ML workflows.

Model deployment process after training:
April 2, 2025
JFrog Survey Surfaces Limited DevSecOps Gains

A global survey of 1,402 application developers, cybersecurity and IT operations professionals finds 71% work for organizations that, despite any potential vulnerabilities, still allow developers to download packages directly from the internet.

Conducted by Atomik Research on behalf of JFrog, the survey also finds less than half of respondents (43%) indicating their organization is scanning at the source code and binary level, with 40% admitting they lack full visibility into the provenance of software running in production environments.

Paul Davis, field CTO for JFrog, said that while a lot of progress has been made in terms of adopting best DevSecOps practices, the survey makes it clear that there is still much work to be done when it comes to securing software supply chains.

The challenge remains finding a way to augment existing software engineering workflows in a way that application development teams will trust and find easy to embrace, he added.

For example, the survey finds nearly three quarters of respondents (73%) work for organizations that have deployed seven or more security tools and platforms, with nearly half (49%) using 10 or more. However, it’s not clear how often these tools are actually turned on given the number of false positives that are generated.

In fact, the JFrog report notes that security researchers disclosed more than 33,000 critical vulnerabilities and exposes in 2024, but JFrog research found only 12% of the high-profile CVEs rated “critical” by government organizations justify the severity assigned based on how exploitable they really are. A deeper analysis of 183 notable CVEs found 63 to never be exploitable in the applications scanned.

At the same time, however, the overall threat to software supply chains continues to grow as more software packages are downloaded. The average organization adds 458 new packages a year, which, on average, equates to 38 a month.

More challenging still, two-thirds of organizations (64%) report using seven or more programming languages, with 44% using 10 or more. Public repositories, meanwhile, continue to grow, with Docker Hub adding 1.9M images in 2024 and Hugging Face adding a million. An analysis conducted by JFrog found 25,229 exposed secrets/tokens in public registries.

As more organizations also rely on public repositories such as Hugging face to invoke artificial intelligence (AI) models the need to secure application programming interfaces (APIs) will also soon become more pressing, noted Davis.

Ultimately, cybersecurity teams need to find a way to work more closely with developers, said Davis. Given the tsunami of alerts that turn out to be false positives, simply creating lists of vulnerabilities that application developers should scan for is not going to significantly improve the overall state of application security, he added. Instead, cybersecurity teams need to become directly involved by, for example, focusing on training a handful of application developers on how to recognize security issues that they will then, by example, permeate through the rest of the software engineering team, said Davis.

Each organization will, of course, need to determine how best to implement DevSecOps workflows but given how brittle many software engineering workflows already are today the challenge goes well beyond simply making some additional scanning tools available to an application developers that, almost by definition, are always going to have a limited amount of security expertise.

April 1, 2025
Checkmarx Extends DevSecOps Reach to Repository Security and Secrets Discovery

Checkmarx this week extended the scope of its ability to protect software supply chains with tools that access how secure a repository is and find where application secrets have been shared in a way that is not secure.

Ori Bendet, vice president of product management for Checkmarx, said the Repository Health and Secrets Detection tools are now part of a Checkmarx One platform that already provides software composition analysis (SCA) tools to scan for malicious code in software packages, containers and artificial intelligence (AI) models.

The need to assess the level of security attained by a repository has become a more pressing concern because cybercriminals have become more adept at impersonating legitimate contributors to the software development project, said Bendet. The Repository Health tool makes it possible to, for example, determine whether multifactor authentication (MFA) is being used to verify the identity of contributors.

The Secrets Detection tool, meanwhile, makes it possible to discover application secrets that might have been, for example, shared as plain text via a messaging platform, added Bendet. The challenge that DevSecOps teams regularly encounter is that these secrets can wind up being inadvertently being stored anywhere as members of a development team collaborate to build an application, he noted.

The Checkmarx One is based on a platform that the company gained with the acquisition of Dustico in 2021. Since then, Checkmarx has been steadily extending the capabilities of that core platform to provide a more holistic approach to software supply chain security based on the Supply-chain Levels for Software Artifacts (SLSA) framework, said Bendet. Checkmarx is the only provider of a security platform that implements that framework in its entirety, he added.

In general, Checkmarx provides a multi-tier approach to assessing threats. The first tier is based on a scan that is then augmented using machine learning algorithms and other forms of artificial intelligence (AI) to assess code. Checkmarx security researchers then review findings to verify the nature of the threat, noted Bendet.

There is no doubt that software supply chain security has become a major concern. A Checkmarx survey recently found that 63% of respondents work for organizations that have been the victim of an attack on their software supply chain in the past two years.

It’s not clear how aggressively organizations are moving to secure software supply chains in the wake of some infamous breaches, but a Techstrong Research survey finds less than half (47%) of respondents work for organizations that regularly employ best DevSecOps practices. However, 54% of respondents regularly practice code scanning for vulnerabilities during development, while 40% conduct security testing. A full 59% of respondents said they are also making further investments in application security, with 19% describing their investment level as high. At the same time, 64% of respondents are investing in a code scanning tool, with 24% describing those investments as high.

Ultimately, as regulations continue to become more stringent it’s more a question of when and to what degree organizations will improve software supply chain security.

The days when organizations were not held accountable for vulnerabilities in their code that cybercriminals found a way to exploit are all bit over. The issue now is finding the best way to ensure code is secure without unduly slowing down the pace at which modern applications are now being developed.

November 21, 2024
Survey Surfaces Software Supply Chain Security Gains

A survey of 106 leaders and practitioners involved in software supply chain security finds more than three-quarters of respondents (76%) work for organizations that have made software supply chain security a significant or top (24%) priority.

Conducted by Anchore, a provider of a software composition analysis (SCA) tool, the survey also finds that 59% of respondents are part of a cross-functional or dedicated team focused on software supply chain security.

Verifying the security of third-party software (46%), the security of open-source software (42%) and the security of the development toolchain (34%) are the top three challenges organizations are encountering. The top priorities are to reduce open-source risk (31%), automate scans across the software development lifecycle (26%), and improve the security of the DevOps toolchain (17%).

Overall, 40% of respondents report their software supply chain has been attacked in the past 12 months, with 21% experiencing a significant impact. Just under a quarter (24%) discovered multiple attacks.

On the plus side, nearly half (49%) are now creating software bills of materials (SBOMs), with 78% planning to increase their usage in the next 18 months. Under half of respondents follow best practices like creating SBOMs for software they develop (49%) or open source software they use (45%) or request from vendors (41%).

Only 10% of respondents currently have a strategy for using the Vulnerability Exploitability Exchange (VEX) format, while 12% consume VEX docs and 8% produce them. One-quarter of respondents expect to adopt VEX in the next six months, and another 15-20% plan to adopt it within 18 months.

Additionally, only 21% of respondents have full visibility of the open-source software components their organization uses, the survey finds.

Josh Bressers, vice president of security for Anchore, said that while there is much work still to be done increased usage of SBOMs suggests that a lot of progress in terms of adopting best DevSecOps practices is being made. Much of that progress is being driven by compliance requirements that are becoming more stringent, he added.

The survey finds on average organizations now comply with 4.9 regulations and standards and well over a third (35%) are making a significant effort to comply with government regulations and standards.

In the long term, a majority of respondents are concerned about the impact artificial intelligence (AI) will have on software supply chain security. The biggest concerns are with code tested with AI (35%) and code generated with AI (32%) or with Copilots (27%).

In general, investment in DevSecOps continues to increase. A separate Techstong Research survey finds that while less than half (47%) of respondents work for organizations that regularly employ best DevSecOps practices, a full 59% of respondents said they are also making further investments in application security, with 19% describing their investment level as high. At the same time, 64% of respondents are investing in a code scanning tool, with 24% describing those investments as high, as well.

As a result, it’s now more a question of when and to what degree the security of software supply chains is about to improve.

November 7, 2024
Survey Surfaces Troubling Signs of Software Supply Chain Insecurity

A global survey of 1,224 software engineering professionals working at organizations with more than 1,000 employees suggests a significant gap has emerged between what senior executives believe is being done to improve application security and what might actually be occurring.

Conducted by Atomik Research on behalf of JFrog, a provider of a DevSecOps platform, the survey finds that 67% of the 331 executives and managers surveyed believe code-level security scans are conducted regularly but only 41% of the developers concurred.

A full 88% of executives also said they believe artificial intelligence AI and machine learning tools are being used for security scanning and remediation processes. However, only 60% of DevSecOps teams reported they are actually using these tools. Just over 90% of executives also believe they are using machine learning models in their software applications, whereas only 63% of developers confirm that is true.

Similarly, 92% of executives claim their organizations possess tools to detect malicious open-source packages, while only 70% of developers agreed.

JFrog Field CISO Paul Davis said the disconnect between executives and rank-and-file developers most likely stems from the simple fact many organizations are still on the journey when it comes to re-engineering DevSecOps workflows. The challenge is each organization is starting that journey from a different place and as such they are progressing at different paces that are often difficult to quantify.

Making matters more challenging, however, is the fact that only 30% of all survey respondents identified the need to address vulnerabilities in their software supply chain as a top security concern. It’s not exactly apparent why less than a third of respondents are concerned about vulnerabilities despite their prevalence but the survey results suggest there is either a level of potential overconfidence or that other more pressing issues might be taking precedence.

Securing Software Supply Chains With or Without Regulation

It’s not clear how much influence regulations might have on spurring organizations to better secure their software supply chains. The European Union (EU), for example, is advancing the Cyber Resilience Act (CRA) that requires organizations to secure the software supply chain for any software that is sold, but other countries have yet to follow suit. In the absence of an actual regulation, it’s up to each organization to determine how best to secure its software supply chain against cyberattacks.

The most common form of those attacks typically involves stealing the credentials needed to access an application development environment. Once cybercriminals gain access, they will over an extended period attempt to embed malware into a workflow in the hopes that malware will find its way into multiple downstream applications. At the same time, cybercriminals are also targeting open-source software repositories by pretending to be interested contributors, before similarly injecting malware into a tool or software component that might be used by thousands of organizations.

Hopefully, advances in artificial intelligence (AI) will soon make it easier to identify and remediate these types of threats. In the meantime, however, the level of disconnect between developers and managers concerning what is being done to ensure software supply chains are secure is, at the very least, disconcerting.

July 19, 2024
Survey Surfaces Lots of Software Supply Chain Insecurity

A global survey of 900 application security professionals finds nearly two-thirds work for organizations that have had their software supply chains compromised in the past two years, with 18% being victimized in the last year.

Conducted by Checkmarx, a provider of application security testing tools, the survey also finds that 100% of respondents are aware of a breach of their software supply chain that occurred at some point in the past.

Not surprisingly, the survey finds three-quarters of respondents (75%) are now either very concerned (39%) or concerned (36%) about the security of their software supply chain.

Additionally, well over half (57%) said software supply chain security is a top or significant area of focus, with 54% planning to use or investigate some type of solution. However, only 7% have acquired and implemented a tool or platform to specifically secure their software supply chains, the survey finds.

On the plus side, half (50%) are now requesting software bill of materials (SBOMs) from entities that provide their organization with software, but fewer than half (47%) said their organization can effectively operationalize SBOMs, the survey finds.

Renny Shen, vice president of portfolio marketing for Checkmarx, said the challenge is the scope of the effort required to secure software supply chains is significant. In addition to SBOMs and deploying tooling to discover vulnerabilities and malware, DevSecOps teams also need to, for example, embrace zero-trust initiatives to secure access to their software supply chain.

There is no single tool or platform that enables DevSecOps teams to achieve that goal, he added.

In general, securing software remains challenging because even if a vulnerability is discovered a DevSecOps team may not be able to fix it, noted Shen. For example, well over half (56%) of the applications deployed are based on open-source code packages that organizations are dependent on external maintainers to update.

On the plus side, however, software supply chain security has become a C-level discussion, said Shen. The challenge is that many organizations have yet to define a set of key performance indicators (KPIs) that enable them to ensure best DevSecOps practices are being adopted. Right now, there is not enough emphasis on application security so developers will continue to focus most of their time and effort on writing new code rather than fixing existing code, he noted.

Unfortunately, most organizations don’t prioritize application security so until there is a fundamental shift in incentives it’s not likely developers will spend more time remediating vulnerabilities. There has been an effort to shift more responsibility for security further left toward developers, which has been met with mixed success. Developers generally have access to more tools but unless those tools are surfacing issues as developers write code it’s not likely they will have a meaningful impact on improving the overall state of application security.

Hopefully, the rise of generative artificial intelligence (AI) will soon make it simpler to find and remediate vulnerabilities by, for example, automatically creating the required patch. In the meantime, however, securing software supply chains requires a level of vigilance that despite best intentions remains difficult to achieve and maintain.

July 3, 2024
OX Security Optimizes DevSecOps to Improve Application Security

OX Security this week updated its application security posture management (ASPM) platform to enable DevSecOps teams to instantly identify applications running in production environments that are running code that could be potentially exploited.

The ASPM platform from OX Security leverages large language models (LLMs) to identify vulnerabilities. The latest version adds an ability to confine the number of alerts generated to instances of code that can actually be exploited.

OX Security CEO Neatsun Ziv said that approach reduces the number of alerts that would otherwise be generated by 99% to enable DevSecOps teams to focus their limited resources on the 1% of alerts that represent an actual risk to the business. OX Security achieves that goal in part because its scanners are integrated with source control, continuous integration/continuous delivery (CI/CD) platforms, registries and cloud computing environments.

The overall goal is to reduce the amount of manual effort currently required to consistently maintain DevSecOps best practices.
The primary reason many vulnerabilities are never addressed is that DevSecOps teams are simply overwhelmed by alerts. Most of the alerts generated by a cybersecurity team are not immediately relevant because either the vulnerability is not present in the application running in a production environment or the application doesn’t connect to the internet.

The OX Security platform makes it possible to identify application security issues that need to be prioritized because it has been confirmed a vulnerability exists that can be exploited, said Ziv.

No matter how precise the alert process becomes, a DevSecOps team will still need to manage it, added Ziv. However, as the alerts generated become more relevant, it should become easier to bridge the historic divide between application developers and cybersecurity teams. Too many developers routinely ignore vulnerabilities identified by cybersecurity teams simply because previous efforts to identify the actual severity they represent have ultimately been a waste of their time.

The challenge just about any organization encounters when trying to better secure their software supply chains is, not surprisingly, getting application developers to buy into the DevSecOps process. Most developers are going to actively resist any approach to remediating vulnerabilities that takes time away from building new applications. Most of them only allocate about 10% of their time or less to remediating vulnerabilities. As such, it’s incumbent on a DevSecOps team to find ways to address application security issues in ways that don’t adversely impact developer productivity.

Organizations could mandate that vulnerabilities be remediated. In fact, there is a growing body of regulations that will require organizations to do just that unless they can prove the vulnerability in question cannot be exploited. The only way to effectively make that case will be to rely more on automation to document that the code running in a production environment is actually secure.

In the meantime, developers should expect to see their code scrutinized more than ever. Of course, the better part of valor is to ensure that as many vulnerabilities as possible are never introduced.

February 1, 2024
Sysdig Identifies Cyberattacks on GitLab Platforms Using Binaries

The Sysdig Threat Research Team (TRT) has uncovered this week that cyberattacks using binaries written in Go and .NET compromise instances of the on-premises editions of the GitLab continuous integration/continuous delivery (CI/CD) platform.

Michael Clark, director of threat research for Sysdig, said most attacks against software supply chains employ scripts. Cybercriminals that appear to be based in Russia are using binaries to launch proxyjacking and cryptomining campaigns utilizing infrastructure resources used to host instances of GitLab.

Cryptomining is the process used to validate cryptocurrency transactions. Proxyjacking involves reselling bandwidth to providers of proxyware services to allow someone to hide their physical location.

The Sysdig research effort, dubbed LABRAT, also noted that the tactics and techniques used to launch attacks are reasonably sophisticated. In addition to using binaries, the cybercriminals also employ tools with undetected signatures, cross-platform malware designed to evade cybersecurity platforms, a command and control (C2) platform that bypasses firewalls and kernel-based rootkits to hide their presence. Furthermore, the attackers abused a legitimate service, TryCloudFlare, to obfuscate their C2 network.

The attacker, still active, is also continuously updating their tools, which requires organizations running GitLab to track the tactics, techniques and procedures (TTP) being employed by the cyberattacker to keep their indicators of compromise (IoCs) list updated.

Relative to the illicit revenue that might be gained from cryptojacking and proxyjacking, this cyberattack is noteworthy in its sophistication. What is less clear is the degree to which this attack might also be used to inject vulnerabilities into the software supply chains based on the GitLab platform.

The one certain thing is that cybercriminals have developed more advanced capabilities for compromising software supply chains that are likely to be used to compromise multiple DevOps platforms.

Fortunately, there’s a lot more focus on securing software supply chains in the wake of a series of high-profile breaches. The challenge is most efforts are still relatively nascent. As such, there isn’t a high enough appreciation for the lengths cybercriminals might go to compromise a software supply chain. The ability to inject malware that might one day find its way into any number of downstream applications makes a software supply chain a tempting target.

Multiple legislative initiatives have been launched that eventually will require organizations to better secure software supply chains. As such, most DevOps teams would be well-advised to begin those efforts now. Some aspects of the proposals being debated today eventually will become law. Rather than trying to comply with a requirement, a more methodical approach to ensuring the security of software supply chains would create less stress for all concerned later.

In the meantime, thanks to the adoption of DevSecOps best practices application security continues to steadily improve. The issue stands that those advances are not being made as quickly as cybercriminals are evolving new tactics and techniques.

August 18, 2023
Extending the GitOps Pipeline: DevSecOps and Trusted Application Delivery
We live in a fast-paced world of rapid changes and uncertainty where every aspect of our daily lives changes often, including the way we work and communicate. Organizations must deliver value to their customers at a much faster pace than ever before to thrive in such an environment. However, the decentralized nature of cloud infrastructure expands the threat landscape and poses several security risks that enterprises should address in light of recent data breaches.

Organizations must combat security threats and address challenges arising from cloud misconfigurations. Several recent tools, strategies, practices and technologies have emerged that can help you handle such security threats. This article discusses how the fusion of DevSecOps and trusted application delivery can extend the GitOps pipeline and add business value.

What is GitOps?

Coined by Weaveworks in 2017, GitOps thrives on a source code management system built on Git and adheres to the belief that Git is the single and definitive source of truth. Since all changes are stored in Git, anyone can see the audit trail if necessary. This enables you to use Git-based version control to manage your application’s code, environment and processes.
```
Figure 1: CI/CD with Git-based Version Control
```
GitOps leverages Git repositories as the one and only source of truth and embraces DevOps and infrastructure-as-code (IaC) best practices. Using GitOps, your developers can spend more time developing applications than configuring or maintaining Kubernetes clusters.

GitOps strategies are gaining traction with enterprises for various reasons, including improved productivity, increased deployment frequency and improved security. While it’s true that GitOps continues to be a transformative trend, the increased speed and automation can also lead to misconfigurations that compromise application stability and security.
```
Figure 2: CI/CD using GitOps
```
Often, these security vulnerabilities delay development as developers spend significant time and effort investigating them. Since this poses a hindrance to progress, the question that arises is how enterprises can maintain the frequency and speed of deployment while remaining secure and reliable. This is where trusted delivery comes in.

An Extension of DevOps

DevOps is a software engineering practice and culture that blends development and operations to provide a shared and collaborative approach to developing and maintaining software. This can boost productivity, lower costs and increase customer value through increased collaboration.

GitOps extends DevOps to bring the deployment workflow closer to developers. GitOps integrates code and configuration management for cloud-native application deployment and administration, while DevOps fosters shared ownership, transparency, and rapid feedback.

GitOps uses DevOps-proven practices like version control, code review and CI/CD pipelines with any Git-based repository, including GitHub, GitLab or BitBucket. It builds on DevOps and applies DevOps best practices for infrastructure automation.

What is Policy-as-Code?

When deploying and managing cloud-native infrastructures, adhering to security best practices and regulatory standards is critical without hindering development. Policy-as-code is an approach to infrastructure security in which rules are codified and enforced, thereby reducing or eliminating human errors. You can use it to write applications using a high-level language to control, manage and automate policies. With policy-as-code in place, developers may create applications to manage security, compliance and other regulations seamlessly.

Here are the types of policies that you can codify:
- Security Policies: By adhering to these policies, you can protect your software from data breaches caused by misconfigurations.
- Resilience Policies: The use of these policies in your Kubernetes clusters will help you create highly available, fault-tolerant systems as well as maintain business continuity.
- Coding Standards Policies: These policies can enforce coding consistency, i.e., any code that violates these policies will be rejected automatically by the system.
What is Trusted Application Delivery?

Trusted delivery entails codifying security policies within your software delivery pipeline for security and compliance and introducing guardrails at every stage. By ensuring the security, integrity and reliability of your applications deployed in production environments, unauthorized access, tampering or malware introduction is minimized. It establishes and maintains trust in application source code, artifacts and deployment pipelines throughout the SDLC process.

The key objectives of trusted application delivery are:
- Security: It protects the application from security threats and vulnerabilities
- Integrity: It verifies the authenticity and integrity of the source code of your application, together with the dependencies, and any artifacts
- Reliability: It ensures that the applications deployed to the production are stable and are devoid of any security loopholes so that they can perform as desired
Trusted application delivery helps development teams release applications early and secures them with automated protections or guardrails. It extends the GitOps pipeline by integrating security, governance and verification with policy-as-code. These security measures are implemented with policy-as-code. The policy-as-code approach encompasses the entire SDLC, including the design, development, testing and deployment stages.

According to your organization’s security and compliance policies, compliance and security rules are codified and integrated into the system. Throughout the life cycle of your application, you can manage its security, compliance and other regulations using policy-as-code. These code-defined policies prohibit the provisioning of non-compliant resources. You should implement trusted application delivery practices to secure your organization’s application delivery process and reduce the likelihood of unauthorized access.

Here are the key benefits of trusted delivery:
- Faster and more frequent releases
- Enhanced security
- Protect against misconfigurations
- Avoid compliance violations
- Improved collaboration
What is DevSecOps?

DevSecOps is a software development methodology that blends development (Dev), security (Sec) and operations (Ops) at all phases of the SDLC by incorporating mandatory security checks. An organization of any size can benefit by creating a culture of shared responsibility and collaboration by bridging the gap between development, security and operations teams.

A DevSecOps pipeline adds practices such as scanning, policy enforcement, static code analysis, threat intelligence and compliance validation to the SDLC process. Contrary to traditional software development processes that treat security as an afterthought leading to security vulnerabilities and breaches, DevSecOps is a paradigm shift that fosters a culture of proactive and continuous security approach to help address security concerns and vulnerabilities.

DevSecOps and GitOps help organizations adapt quickly to changing emerging trends and requirements. DevSecOps is an offshoot of DevOps that focuses primarily on security throughout the development process. It helps detect and resolve security issues and vulnerabilities easily and quickly while fostering a culture of continuous improvement.

Here are the benefits of DevSecOps at a glance:
- At the outset, determine which points in the SDLC process are susceptible to security flaws and vulnerabilities in the SDLC process
- Streamlined compliance
- Secure supply chain
- Reduced risk of the attack surface
- Complete visibility of potential threats
Why DevSecOps?

DevSecOps is a proven way to secure your CI/CD pipelines, deliver secure, trusted, high-quality software and foster an environment where security is the responsibility of everyone in the organization. By shifting security left—i.e., introducing security into the CI/CD pipeline earlier—organizations can be much more productive and the teams can be more cooperative and collaborative.

Given the threats to the security of the software supply chain, DevOps practices have given way to DevSecOps practices, where safety is paramount and a fundamental and ongoing component of software development. At the outset of the SDLC, you should ensure that software components and dependencies are secure to avoid potential software supply chain hazards.

Additionally, it would help if you had built-in security gates in each step of the SDLC to ensure consistent, repeatable and automated processes from the software build phase to deployment. Remember, DevSecOps isn’t an option; instead, it is a necessity.

Trusted Delivery With GitOps

Automated software delivery pipelines are based on Git as the only source of truth. Policy-as-code is a great way to ensure that misconfigurations and errors are detected, alerted, and deployments halted automatically. Next, we’ll cover how a typical GitOps workflow determines where multiple checkpoints can be implemented for trusted delivery.

In a typical workflow based on GitOps, a developer commits the source code to a Git repository. The CI tool then builds the container images. These container images are then tested and then uploaded to an image repository. At the end of this process, these container images will be deployed to a Kubernetes cluster. GitOps agents compare the current cluster state with the desired state on a continuous basis.

Hence, you should implement security guardrails at the following points:
- Git repository
- CI stage
- Configuration repository
- Kubernetes cluster
Creating a Trusted Software Supply Chain With DevSecOps

You can build a trusted software supply chain by incorporating security practices throughout the SDLC to ensure the integrity and security of the software delivered by DevSecOps. Here is a step-by-step guide to building a trusted software supply chain by leveraging DevSecOps principles:
- Security by Design: You should integrate security right from the outset of the SDLC and identify the key threats to the security of the pipeline.
- Application Dependency Scanning: When building applications, we often use third-party dependencies to accelerate the development process. You should monitor security vulnerabilities and patches as they become available for these dependencies. You can leverage OWASP Dependency Check, Firewall from Sonatype, etc.
- Secure Coding Practices: You should adhere to and enforce these practices among your development teams. You can integrate static code analysis tools into your DevSecOps pipeline, conduct regular code reviews and identify and fix security issues.
- Container Security: You should scan container images regularly for security vulnerabilities, implement strategies to secure your containers and use container registries with access controls.
- Continuous Compliance: You should ensure the software supply chain adheres to the relevant standards and guidelines for compliance requirements. In this regard, you should conduct audits regularly to check if compliance requirements have been satisfied.
- Collaboration and Communication: You should be able to foster a culture in your organization that facilitates collaboration and communication across the development, operations and security teams.
DevOps, DevSecOps and GitOps: The Future

As organizations strive to optimize the efficiency of their software supply chain, DevOps, DevSecOps and GitOps are approaches that can improve collaboration, efficiency and security, to help software developers and IT operations succeed. These practices would become more critical and widely used in the future. GitOps provides teams with better tools for managing configurations so they can focus on more strategic activities.

While GitOps is an approach that advocates Git-based version control systems as the single source of truth, DevOps is concerned about a cross-functional team that can work together. DevSecOps goes a step further by blending security into all stages of the SDLC process.

The future of DevOps, DevSecOps and GitOps will see increased automation, tighter security integration and a sustained emphasis on efficiency and collaboration. Your organization should adopt these approaches to provide reliable software and services to its customers.

Conclusion

Trusted application delivery is essential for securing applications, protecting user data, meeting compliance requirements and preserving market credibility and trust. It helps enterprises and end consumers by ensuring that software is distributed securely and reliably. Organizations can ship high-quality applications with guaranteed security and performance by adopting trusted delivery practices.
July 28, 2023