devopsy.kinsta.cloud

Tag: code scanning

GitHub’s Security Autofix Agent Now Remembers What It Fixed

Most codebases have a favorite mistake. It might be a query built from string concatenation, or a missing check on user input. A developer fixes it in one file. A few weeks later, the scanner finds the same flaw in another file, and the fix starts from scratch.

GitHub wants to stop paying for that lesson twice. On September 25, the company said agentic autofix now uses Copilot Memory for customers who have turned Memory on. Before the agent works on a security alert, it checks stored memories for context that might help. After it creates a fix, it saves the fix pattern as a memory for later use.

Those patterns don’t stay inside autofix. According to GitHub’s changelog, they help the agent resolve other security alerts, and they inform other Copilot features, including code review and the Copilot cloud agent, about secure development practices specific to the repository.

Both agentic autofix and Copilot Memory are still in public preview.

How the Pieces Fit

Agentic autofix entered public preview on July 10. Instead of a one-shot suggestion, a developer assigns a code scanning alert to Copilot. The agent explores relevant files, proposes a fix, and reruns CodeQL to confirm the alert is gone. If it isn’t, the agent tries again. Then it opens a draft pull request that explains the fix. GitHub says this usually takes two to four minutes.

The feature requires a GitHub Code Security or Advanced Security license, plus a Copilot license with the cloud agent enabled. It also uses the organization’s AI credits and GitHub Actions minutes.

Copilot Memory is the other half. It stores two kinds of information: facts about a repository, such as coding conventions, architecture decisions, and build commands, and a user’s personal preferences. Repository facts stay in the repository where they were learned.

The design detail that matters most here is validation. GitHub’s documentation says repository facts are stored “with citations pointing to the code that supports them.” Before Copilot uses a fact, it checks those citations against the current branch. Only validated facts get used. And any fact that goes unused for 28 days is deleted automatically.

For individual plans, Memory is on by default. For plans managed by an organization or enterprise, an administrator has to enable the policy first. So in most enterprise shops, this update does nothing until someone makes that call.

From Fixing to Preventing

The interesting part isn’t that autofix gets a little smarter. It’s that a fix now teaches the rest of the toolchain.

In most organizations, security knowledge dies in the pull request. A developer fixes an alert, and the next developer who makes the same mistake never sees the fix.

With memory in the loop, a fix pattern can reach code review. If Copilot code review knows how this repository handles a certain class of vulnerability, it has a better chance of flagging the same mistake in a new pull request before it merges. That moves the work earlier, from cleaning up alerts to catching them in review.

Mitch Ashley, vice president and practice lead for CIO & technology buyers and software lifecycle engineering at The Futurum Group, sees a bigger point in how GitHub built it. “GitHub’s move matters because of what it says about agent trust. A system earns trust by showing its work, not by producing more of it,” he says. “Tying a fix pattern to citations that expire once the code changes is a real step toward self-evidencing agent memory, a piece most agentic tooling still lacks.”

Questions to Ask First

This is a preview, and teams should treat it that way. A few things are worth checking before you rely on it.

First, what gets remembered, and when? The changelog says autofix saves the fix pattern when it creates a fix. It doesn’t say whether that happens before or after a human approves the pull request. Ashley thinks that detail carries a lot of weight. “Whether autofix banks a pattern before or after a human approves the fix will decide how much this helps. Bank it too early, and a weak pattern can spread faster than review catches it.”

Second, who turns it on? In an enterprise, the Memory policy is an admin decision. Security and platform teams should make it together.

Third, what does it cost? Every agentic autofix run uses AI credits and Actions minutes. If memory helps the agent clear more alerts, usage may rise.

Fourth, how long do lessons last? The 28-day expiry keeps stale facts from piling up. It also means a pattern tied to a rare class of bug may fade before that bug shows up again.

The Bigger Picture

AI coding agents have mostly worked like contractors who show up with no notes from the last job. Memory changes that. It gives an agent a record of how a specific team writes and secures its code.

That’s useful. It’s also a new thing to govern. Teams will need to know what’s in an agent’s memory and where it came from.

For DevOps teams, the practical step is simple. If you’re already testing agentic autofix, turn on Memory in a few repositories with a steady flow of security alerts. Then watch whether the same findings stop coming back. And watch your own team, too. “Watch whether teams that enable Memory also tighten scrutiny of agent-written fixes instead of just clearing more alerts,” Ashley says.

September 28, 2026
Endor Labs Adds AI SAST Tool to Discover Vulnerabilities in Code

Endor Labs has developed a static application security testing (SAST) tool that leverages agentic artificial intelligence (AI) to more accurately identify vulnerabilities and other issues in code created in more than 40 programming languages.

Amod Gupta, vice president of product and design for Endor Labs, said the AI SAST tool the company develops combines a multi-modal static analysis engine, multiple AI agents and large language models (LLMs) to create the equivalent of a security engineer that analyzes code as it is developed.

The AI agents were built using a proprietary code application programming interface (API) that builds a model of how the code works in a way that provides additional context about the organization, added Gupta.

That approach enables the AI SAST tool to filter false positives by analyzing syntax, dataflow, and intent to reduce the number of false positives that SAST tools have historically generated by 92% on average, the company claims.

SAST AI will also review code for architectural and business logic flaws, such as broken access control and insecure design, and classify findings against the OWASP Top 10 security vulnerabilities framework. The AI agents will then surface recommendations to fix code based on the context they have been able to establish.

Finally, DevSecOps teams can also use natural-language prompts to teach SAST AI about specific practices and policies.

The SAST AI tool is arriving at a time when developers are relying on AI coding tools to generate more code than ever. That challenge is that AI coding tools typically invoke a general-purpose LLM that was trained using examples of code pulled from across the web that were often deeply flawed. The end result is that many of these tools are generating vulnerabilities in code that, on average, require 15 to 30 minutes each to triage.

Unfortunately, many application developers lack the cybersecurity expertise required to identify many of the vulnerabilities being generated. It’s then left to DevSecOps engineers to discover and remediate the rest before code is added to a production environment. Despite their best efforts, however, there are a lot more application developers than there are DevSecOps engineers, so more vulnerabilities are inevitably going to find their way into production environments.

The only way to break that cycle is to rely on AI to discover and help remediate the vulnerabilities being generated by AI coding tools, said Gupta. The issue is that organizations can not rely on the same LLM that was used to create code to also analyze that code for vulnerabilities, he added.

It’s probable that application security in the age of AI will get worse before it eventually gets better. Existing tools for analyzing code are often ignored by developers simply because they generate too many false positive alerts. As AI is incorporated into SAST tools, however, the overall level of noise generated by these tools should decline. In the meantime, DevOps teams should exercise more care. After all, if more of the code being created by AI tools winds up creating more security issues, the whole point of being able to build software faster becomes self-defeating.

November 25, 2025
appCD Launches Platform to Securely Provision Cloud Infrastructure

appCD this week launched a namesake platform that analyzes an application about to be deployed to automatically generate the code needed to provision the IT infrastructure required.

Fresh from raising $6 million in seed funding, appCD CEO Sachin Aggarwal said that approach makes it possible to consistently create secure code for provisioning IT infrastructure versus requiring developers with little to no cybersecurity to manually write it.

Instead, appCD reviews Python or Java code to understand intent, identifies dependencies and then infers application programming interface (API), service configuration, ingress/egress and other environment variables. Terraform code or Helm charts are then automatically generated based on the static analysis of the code that has been reinforced using artificial intelligence (AI) learning techniques.

That approach also makes it simpler for platform engineering teams to centrally manage the provisioning of IT infrastructure using a set of pre-defined policies that are automatically implemented each time an application is deployed to ensure security by default, he added.

DevOps teams can also use appCD to visualize the deployment environment before and after an application is deployed, said Aggarwal.

While infrastructure-as-code (IaC) tools have accelerated the rate at which cloud infrastructure can be provisioned, they are also often the root cause of the security issues that plague cloud computing environments. Developers often misconfigure cloud infrastructure by, for example, inadvertently leaving ports open. The appCD platform reduces the potential such mistakes will be made, noted Aggarwal.

That capability also eliminates the need to attach cybersecurity specialists to a DevOps team because issues are automatically resolved by the guardrails enforced by appCD, he added.

In theory, at least, there may soon come a day when AI routinely improves the quality of the code being used to both build and deploy applications. The more the code used to train a large language model (LLM) is vetted, the more reliable the output becomes. In the meantime, platforms such as appCD are combining static analysis with AI reinforcement learning to achieve that same goal in a use case that is specific to generating code to provision IT infrastructure.

Each DevOps team will naturally need to determine the best path forward, but as regulations pertaining to securing software supply chains become more stringent, it’s only a matter of time before organizations will be required to embrace DevSecOps workflows. In the meantime, DevOps teams should assume that given the probability cloud infrastructure has been misconfigured, it’s all but certain there will be multiple cloud security incidents. In fact, cybercriminals are actively scanning for misconfigurations that they have already created playbooks to specifically exploit in a matter of minutes.

In the absence of being able to prevent all those issues from arising, the immediate priority becomes remediating as many issues as possible before cybercriminals exploit those vulnerabilities. However, it’s also important to draw a proverbial line in the sand to ensure that all cloud infrastructure being provisioned in the future is much more secure than it has tended to be thus far.

March 7, 2024
5 Security Threats DevOps Teams Should Know

DevOps security, also known as DevSecOps, is a philosophy in which security practices are integrated into the DevOps process. DevOps security involves creating a ‘security-as-code’ culture with ongoing, flexible collaboration between release engineers and security teams. The DevSecOps movement, much like DevOps itself, is focused on creating new solutions for complex software development processes within an agile framework.

DevOps security is about breaking down silos and promoting open collaboration across teams. It’s about making everyone accountable for security with the ultimate aim of improving the quality and speed of code releases. The adoption of a DevOps security model necessitates a cultural shift across the organization. It requires the integration of security into every aspect of the development and operations processes.

DevOps Security is not just about implementing tools and technologies; it’s about changing the way we look at security. Rather than being an afterthought, security should be a key part of the ongoing conversation from the start of the project to the end.

5 Security Threats DevOps Teams Must Know About

As a DevOps professional, it’s crucial to be aware of the potential threats that could compromise your systems, applications, and data. Let’s take a look at the top five security threats that DevOps teams must be aware of.

Phishing Attacks

Phishing attacks are a common security threat that can lead to data breaches. These attacks involve cybercriminals impersonating legitimate organizations to trick individuals into revealing sensitive information, such as passwords and credit card numbers.

Phishing attacks can be particularly damaging for DevOps teams. They can lead to unauthorized access to development systems and data, which can lead to devastating supply chain attacks. For example, an attacker could trick a team member into revealing their login credentials for a critical system, allowing the attacker to gain access and inject malware into a CI/CD pipeline.

Code Injection

Code injection is another common security threat that DevOps teams must be aware of. This involves the exploitation of an application by injecting malicious code. The attacker can then execute the malicious code to compromise the system or steal sensitive data.

For DevOps teams, code injection attacks can be particularly harmful. These attacks can lead to compromised systems and applications, resulting in data breaches and significant downtime.

Man-in-the-Middle Attacks

Man-in-the-middle attacks are a type of security threat where the attacker intercepts and potentially alters the communication between two parties without their knowledge. This can lead to a range of damaging outcomes, including data theft, session hijacking, and even identity theft.

For DevOps teams, man-in-the-middle attacks can be particularly problematic. These attacks can lead to compromised systems and data, and even the unauthorized alteration of code.

Container Vulnerabilities

Container vulnerabilities are a significant security threat for DevOps teams. Containers are a key technology in the DevOps world, allowing for the rapid and reliable deployment of applications. However, like any technology, they come with their own set of security risks.

These vulnerabilities can range from use of insecure images, to misconfigurations and software bugs, to more serious issues like kernel exploits. If an attacker is able to exploit a container vulnerability, they could potentially gain control over the entire system.

DDoS Attacks

Last but not least, distributed denial-of-service (DDoS) attacks are a significant security threat that DevOps teams must be aware of. These attacks involve overwhelming a production environment with traffic, causing it to become unavailable to users.

For DevOps teams, DDoS attacks can be particularly damaging. Not only can they lead to significant downtime, but they can also result in lost revenue and damage to the organization’s reputation.

How to Mitigate These DevOps Security Threats

While these security threats are concerning, there are effective strategies and techniques that can be used to mitigate them.

Implement Email Security Practices and Tools

To combat phishing attacks, it’s crucial to implement email security tools that can detect and block phishing attempts. These tools can help to filter out phishing emails, reducing the likelihood that team members will fall victim to these attacks.

In addition to implementing email security, it’s also important to provide security awareness training for team members. This training should cover the basics of cybersecurity, including how to recognize and respond to phishing attempts.

Use Input Validation and Sanitization in Applications

To protect against code injection attacks, it’s important to use input validation and sanitization in applications. Input validation involves checking that the data provided by a user meets certain criteria before it’s processed by the application.

Input sanitization, on the other hand, involves cleaning up the data to remove any potentially harmful elements. This can help to prevent malicious code from being executed within the application.

Employ HTTPS and SSL/TLS Encryption for Data in Transit

To guard against man-in-the-middle attacks, it’s important to employ HTTPS and SSL/TLS encryption for data in transit. This ensures that any data being sent between the user and the application is encrypted, making it much more difficult for an attacker to intercept and read the data.

Regularly Scan Containers for Vulnerabilities

To protect against container vulnerabilities, it’s crucial to regularly scan containers for vulnerabilities. This involves using tools that can analyze the containers and identify any potential security risks.

By regularly scanning containers, DevOps teams can identify and address vulnerabilities before they can be exploited by an attacker.

Implement Rate Limiting and Network Filtering

Finally, to mitigate the risk of DDoS attacks, it’s important to implement rate limiting and network filtering. Rate limiting involves restricting the number of requests that a user can make to the application within a certain period of time.

Network filtering, on the other hand, involves blocking traffic from certain IP addresses or ranges that are known to be associated with DDoS attacks. This can help to reduce the impact of a DDoS attack and protect the availability of the application.

In conclusion, DevOps security is a crucial aspect of the DevOps process. By being aware of potential security threats and taking steps to mitigate them, DevOps teams can significantly reduce the risk of a security breach and ensure the ongoing success of their projects.

January 25, 2024
Legit Security Applies AI to Detect Vulnerable Application Secrets

Legit Security today announced it has expanded the scope of its application security posture management (ASPM) platform to make use of artificial intelligence (AI) to discover secrets more accurately in applications that cybercriminals can actually exploit.

Scanners typically generate high false positive rates to the point where developers often start to ignore them. As a result, it’s not uncommon for secrets to be discovered in an application even though an alert was generated.

Legit Security CTO Liav Caspi said the company is now applying a large language model (LLM) specifically trained for source code along with prompt engineering techniques and heuristics to reduce the level of alert noise that developers would otherwise see when scanning for secrets. The overall goal is to correctly identify access keys, passwords, application programming interface (API) keys and other personally identifiable information (PII) that should not be exposed once an application is deployed in a production environment, he noted.

That capability can be applied to detect secrets across all development assets, including code repositories, source code management (SCM) tools, build tools and logs, artifacts and private and public documentation. In addition, this approach also uncovers toxic combinations of secrets or ones that might lie buried within assets such as source code history or modified Confluence pages that developers often forget exist, noted Caspi.

Legit Security also enables DevSecOps teams to apply preventive guardrails on developer endpoints using the Legit command line interface (CLI) to stop secrets from being exposed before code is pushed. In addition, automated workflows can reach developers as part of a pull request or create Slack messages or Jira tickets to streamline remediation. DevSecOps teams can also continuously triage results to create a baseline that includes exceptions.

As part of a larger effort to secure software supply chains, Legit Security has developed a software-as-a-service (SaaS) platform designed to apply security policies across an entire software development life cycle. The company is now extending the capabilities of that platform using AI technologies to detect secrets in both source code and all the components that make up a development pipeline as they are added.

In the wake of an executive order requiring federal agencies to better secure software supply chains, there is now more focus than ever on application security. Unfortunately, many developers are a little too cavalier when it comes to managing secrets during the application development process. They often leave secrets in plain text to facilitate workflows, but more often than many care to admit, those secrets are not removed before an application is deployed. Knowing this, cybercriminals have learned to scan applications for those exposed secrets. Once gained, they then appear to be just another legitimate user of an application that might not be discovered until malware is activated.

It may be a while before the cultural and technical issues that conspire to make the software supply chain insecure are fully addressed. In fact, the problem may get worse before it gets better—simply because the pace at which distributed applications are being built and deployed only continues to accelerate. At the same, the cost of making a secrets mistake is also only going to increase as regulations become more stringent. In fact, it’s now only a matter of time before stiff fines intended to make an example of one or more unfortunate organizations are eventually going to be levied.

January 23, 2024
HashiCorp Acquires BluBracket to Extend Secrets Management Reach

HashiCorp this week revealed it has acquired BluBracket to add a set of scanning tools for discovering static secrets to its portfolio.

James Bayer, senior vice president of research and development for the Secure product line at HashiCorp, said the existing Vault platform for managing secrets is designed to enable developers to manage them as they build applications. BluBracket has developed a secrets management tool that makes it possible to discover secrets in applications that have already been deployed in production environments, he said.

The amount of secrets management-related technical debt many organizations have can be enormous, especially if they’ve been deploying applications for decades. IT teams need a tool that discovers secrets in applications that, in many cases, were deployed by application developers that are no longer with the company, Bayer added.

The BluBracket tools make it possible to discover those unmanaged secrets even before efforts are put in place to improve application security, he noted.

HashiCorp will initially integrate BluBracket’s functionality into HashiCorp Vault to expand HashiCorp’s zero-trust capabilities, and add detection and remediation workflows via additional capabilities expected later this year. That’s critical, because for decades, developers have been storing secrets in applications and forgetting to remove them before an application is deployed.

In general, HashiCorp is moving to transform its Vault platform into an orchestration engine for managing secrets regardless of where those secrets might be stored, said Bayer. That approach will enable developers to build applications and store their secrets on, for example, the Amazon Web Services (AWS) cloud in a way that can be centrally managed via the Vault platform, he added.

Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text, the need to encrypt secrets becomes a higher priority.

The core DevSecOps issue most organizations are wrestling with is how involved cybersecurity teams should be in application development. There’s clearly a concerted effort to push more responsibility for application security further left toward developers. The challenge is, even when those tools are provided, it’s not clear that developers can distinguish between the severity of one vulnerability versus another.

Conversely, most cybersecurity teams don’t really understand how modern applications are developed. That doesn’t necessary mean cybersecurity professionals need to dive deep into application development workflows, but it does mean they should, at the very least, understand how applications are constructed to make sure the appropriate security guardrails have been put in place.

Regardless of approach, it’s clear there is a need for some type of centralized security function to better ensure application security. Unfortunately, the cultural divide between application developers and cybersecurity teams remains fairly wide. The DevSecOps journey ahead will be long, as each organization determines how best to bridge that gap when the supply of available cybersecurity expertise remains constrained.

June 29, 2023
Mobb Launches Community Edition of Automated Remediation Tool

Mobb today made available a free community edition of a namesake tool that creates fixes to open source vulnerabilities. The fixes are based on the results of code scanning by a static application security testing (SAST) tool.

Fresh from raising $5.4 million in seed funding, Mobb CEO Eitan Worcel said the company developed a tool that creates validated patches based on the scan results of third-party SAST tools from Checkmarx, GitHub and Snyk. Initially, the tool is aimed at Java vulnerabilities.

Worcel said that most vulnerabilities can be traced back to eight types of mistakes that developers routinely make. The company created a pattern for those common mistakes, along with patterns to fix them, called Mobb rules. That ability enables Mobb to accurately produce a code fix that both remediates the vulnerability and adheres to the correctness of the language to eliminate code defects. Mobb then makes available a patch to address those issues in a way that can be readily downloaded and applied by developers. Mobb does not automatically apply those fixes because most developers prefer to review them first, noted Worcel.

The Mobb approach eliminates the need for IT teams to sort through SAST scans themselves, which can result in the discovery of thousands of vulnerabilities that might theoretically need to be fixed. Each vulnerability, at minimum, is going to require 30 minutes to fix, so the Mobb platform provides a better return on investment and reduces patch backlogs, added Worcel.

For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing which types of vulnerabilities should have a higher remediation priority.

Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities being discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool addresses that later issue by automatically creating the necessary patch, said Worcel.

Many organizations just allocate junior developers to the task of remediating vulnerabilities, which Worcel noted frees up more experienced developers to focus on writing additional business logic.

There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that have already been developed.

One way or another, the process by which patches are prioritized, developed and then applied has long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities wherever they may be found.

April 17, 2023
Software Supply Chain Risk Management: A 2023 Guide
Software supply chain risk management (SSCRM) refers to the process of identifying, assessing and mitigating risks associated with third-party software components and services that are integrated into software products. SSCRM involves understanding the potential vulnerabilities that may arise from these components and taking measures to reduce the risk of exploitation or compromise to the software system or end-users.

Why Software Supply Chain Attacks are Becoming More Common

Software supply chain attacks have become common due to several factors:
- Larger attack surface: The increased use of third-party software components and services in software development has expanded the attack surface for cybercriminals. This means that attackers can exploit vulnerabilities in these third-party components to gain access to the larger software system.
- Rise of open source: The proliferation of open source software has also contributed to the rise of supply chain attacks as attackers can inject malicious code into open source repositories, which can then be used by developers in their software products.
- Difficulty to detect: Detecting supply chain attacks can be challenging since attackers often use legitimate-looking code that may be difficult to distinguish from normal code. This can make it difficult for traditional security measures to detect the attack. Additionally, the attack may not manifest itself until much later, making it even harder to trace back to its source.
- Automation: Supply chain attacks are also becoming more sophisticated through the use of automation. Attackers can use automated tools to scan for vulnerabilities in third-party components and inject malicious code into them. This means that they can quickly and efficiently compromise a large number of software products.
- Evasion techniques: Attackers can evade traditional security measures through techniques such as code obfuscation and encryption. This makes it difficult for security measures to detect malicious code, which can easily slip through undetected.
- Sophistication: Supply chain attacks are becoming more challenging to combat due to the use of advanced malware techniques to change shape. Attackers can use polymorphic malware that can change its code and behavior to avoid detection. This means that even if the malware is detected, it can quickly change its form to evade detection in the future.
Supply Chain Security and DevSecOps

DevSecOps is an approach that integrates security into all stages of the software development process. Adopting DevSecOps practices can help businesses manage supply chain risks by building security into their software development and delivery pipelines.

Continuous integration/continuous deployment (CI/CD) pipelines are a key component of DevSecOps, as they allow developers to rapidly test and deploy code changes while ensuring that security and compliance requirements are met.

Here are some ways DevOps tools in the CI/CD pipeline can help manage supply chain risks:
- Automating security testing: DevSecOps enables businesses to automate security testing throughout the software development life cycle, including during the development, testing and deployment phases. This can help identify and mitigate security vulnerabilities early in the process, reducing the likelihood of supply chain risks.
- Continuous monitoring: DevSecOps enables continuous monitoring of software and infrastructure, providing real-time visibility into the security posture of the supply chain. This can help identify and respond to security threats quickly and effectively.
- Secure coding practices: DevSecOps encourages the use of secure coding practices, such as input validation, access control and error handling, reducing the likelihood of supply chain risks.
- Risk management: DevSecOps incorporates risk management into the software development process, ensuring that supply chain risks are identified, assessed and managed effectively.
Tools and Solutions to Help Manage Supply Chain Risks

Supply Chain Risk Management (SCRM)

SCRM solutions are software tools and services that help organizations manage and mitigate supply chain risks. These solutions provide visibility into the supply chain operations, identify potential risks and enable organizations to take proactive measures to mitigate these risks.

They may include features such as supplier risk assessments, real-time monitoring of supply chain operations, analytics and reporting and incident response planning. SCRM solutions are often available as a service (SaaS) and can help organizations to enhance supply chain resilience, reduce disruption and ensure business continuity.

Software Composition Analysis (SCA)

Software Composition Analysis (SCA) is a software security practice that involves identifying and managing open source and third-party components used in the development of software applications. SCA tools scan the software codebase, detect and report the presence of third-party and open-source components and identify known vulnerabilities in these components.

SCA helps organizations to identify and manage risks associated with third-party components, including license compliance, intellectual property infringement and security vulnerabilities. SCA is an essential component of SSCRM and can help organizations to ensure the security and integrity of the software products they develop and distribute.

Third-Party and Supplier Risk Management

Third-party and supplier risk management software is designed to help businesses manage the risks associated with their third-party vendors and suppliers. This software provides tools and resources to identify, assess and manage the risks associated with third-party relationships.

Here are some features of third-party and supplier risk management software:
- Supplier management: The software provides tools to manage supplier relationships, including supplier performance monitoring, supplier compliance and supplier risk assessment.
- Risk assessment: The software enables businesses to assess the risks associated with their third-party relationships, including financial risks, operational risks and reputational risks.
- Compliance management: The software helps businesses comply with regulations and standards, such as GDPR, HIPAA and ISO 9001.
- Data analytics: The software uses data analytics tools to help businesses identify trends and patterns in third-party data, enabling them to anticipate and mitigate risks.
- Incident management: The software provides tools to help businesses respond to and manage incidents related to third-party relationships, such as data breaches or compliance violations.
Best Practices for Software Supply Chain Risk Management

The following are some best practices for managing supply chain risks.

Identifying Supply Chain Threats and Potential Weaknesses

The first step in managing supply chain risks is to identify potential threats and vulnerabilities in the supply chain. This involves conducting a comprehensive risk assessment that considers all potential sources of risk, including geopolitical factors, natural disasters, cyber threats and other disruptions. The risk assessment should consider the entire supply chain, including all vendors, suppliers and partners.

During the risk assessment, organizations should identify the critical components and services that are essential to their operations. They should also evaluate the potential impact of a disruption to these critical components and services, including the financial, reputational and operational impact.

Establishing a Supply Chain Risk Management Framework

After identifying potential threats and vulnerabilities, organizations should establish a supply chain risk management framework that outlines the policies, procedures and controls required to mitigate these risks. The risk management framework should be aligned with the organization’s overall risk management strategy and should include the following components:
- Risk management policy: This policy should outline the organization’s approach to supply chain risk management and define the roles and responsibilities of key stakeholders.
- Risk assessment procedures: These procedures should describe how the organization conducts risk assessments, including the criteria used to evaluate risks and the frequency of assessments.
- Risk mitigation controls: These controls should outline the specific measures the organization will take to mitigate identified risks.
- Incident response plan: This plan should describe the steps the organization will take in the event of a supply chain disruption.
Continuously Monitoring Risks

Once the supply chain risk management framework is in place, organizations should continuously monitor supply chain and third-party risks and take proactive measures to mitigate them. This includes establishing a patching cadence to ensure that all software components are up to date and protected against known vulnerabilities.

Organizations should also implement endpoint security controls, such as antivirus software and intrusion detection systems, to protect against malware and other cyber threats. Network security controls, such as firewalls and access controls, should be implemented to protect against unauthorized access to systems and data.

Web application security controls should also be implemented to protect against web-based attacks, such as SQL injection and cross-site scripting. This includes conducting regular vulnerability assessments and penetration testing of web applications.

Promoting a Culture of Awareness

Finally, organizations should promote a culture of awareness among all stakeholders, including employees, vendors, and suppliers. This includes providing risk awareness training to employees, so they understand the risks associated with the supply chain and the steps they can take to mitigate these risks.

Organizations should also communicate their supply chain risk management policies clearly to vendors and suppliers so they understand their obligations and responsibilities in managing supply chain risks. This includes conducting due diligence on vendors and suppliers to ensure they meet security standards and policies.

Conclusion

Managing supply chain risks is a critical task for organizations that rely on third-party vendors and suppliers to deliver goods and services. These risks can arise from a range of sources, including geopolitical factors, natural disasters, cyber threats and other disruptions.

To effectively manage these risks, organizations need to adopt best practices such as identifying threats and potential weaknesses, establishing a supply chain risk management framework, continuously monitoring risks and promoting a culture of awareness.

As we look ahead to 2023, it is clear that software supply chain management will continue to be a priority for organizations across industries. With the increasing complexity of software supply chains and the evolving threat landscape, organizations must remain vigilant in their efforts to identify and mitigate potential risks.
March 24, 2023
The Scariest Things About SCA

It is a time of ghouls, mischievous spirits and David S. Pumpkins. In the spirit of Halloween, here are the top five scariest limitations of software composition analysis (SCA) tools that are enough to send shivers down your spine. Read on … if you dare!

1. SCA Scans Only Your Application Code

SCA’s scope is frightfully narrow. When scanning for vulnerable dependencies, SCA only examines your source code even though vulnerable dependencies used to build your software can exist throughout your entire development pipeline. Vulnerable dependencies can be found in dev tools like Jenkins, dev tool plugins like Jenkins Plugins, build modules like GitHub Actions, build module dependencies like GitHub Actions libraries, and infrastructure-as-code (IaC) dependencies. If you’re only scanning application code, you should be shaking in your boots because it is not enough to protect against modern software supply chain attacks like SolarWinds or Codecov.

The good news is that next-gen SCA, pipeline composition analysis (PCA), scans your application code and your entire pipeline for vulnerable dependencies. PCA improves upon the foundation of SCA by including a deep understanding of the tools, configurations, processes, activities, components and dependencies used at every stage of the delivery pipeline. When new dependencies like Text4Shell are disclosed, you can be sure every instance of the vulnerability is found and remediated. This way you know you don’t have any proverbial skeletons lurking in your software’s closet.

2. SCA Can’t Tell You Where Vulnerabilities Are Deployed

Vulnerability remediation can be ghoulish. When new high-severity exploits are disclosed, you need to remediate every instance of the vulnerability from all production environments where it could be exploited–and you need to do it fast. Identifying a vulnerability like Log4j in your code base is a start, but you’re not truly secure until you have removed every instance of the vulnerability in production systems where they pose a real risk to your organization. Though traditional SCA can tell you where a vulnerability is in your application code, it has no visibility once that code has been deployed.

PCA gives you visibility into your entire development pipeline, including production environments. This enables you to easily trace the path of a vulnerability from code to deployment locations, such as identifying which Kubernetes clusters contain a specific vulnerability. This enables organizations to be more agile in their response to newly disclosed threats and ensures that every instance of a vulnerability has been remediated.

3. SCA Doesn’t Correlate Risk Across AppSec Engines

Some traditional SCA solutions may be able to collect data from various scanning engines, but they are terrible at making meaningful connections between various data points. Because of this, “traditional” SCA is unable to provide the context required to deliver an accurate and nuanced assessment of the impact of one event and how risk might be compounded by other related events. SCA without context generates too many false positives—this results in your team wasting time chasing ghosts.

PCA correlates risks and threats across all phases of the SDLC as well as from all AppSec scanning tools. By connecting the dots from numerous data sources, PCA helps your security and DevSecOps teams understand holistically how risks relate to each other so they can best tackle the most important security initiatives first.

4. SCA Ignores Pipeline Security and Governance

Modern development pipelines are complex and deeply interconnected–almost as if they are stitched and bolted together like Frankenstein‘s creation. Though managing security policies across the entire SDLC is an arduous and painful task, it is essential if you want to prevent software supply chain attacks. Unfortunately, traditional SCA solutions don’t even come close to helping you manage pipeline security and governance policies like enforcing least privilege or hardening authentication.

Pipeline composition analysis identifies pipeline tooling misconfigurations and helps you implement best practices for security controls across your entire pipeline. Even better, to prevent your tooling from being bypassed, PCA alerts you when pipeline security controls like SCA scanning are removed or disabled.

5. SCA Provides No Visibility into Your SDLC

Traditional SCA solutions focus only on application code. They provide no visibility across your SDLC. They were not designed to scan development and deployment environments, so they cannot secure the later parts of your SDLC. SolarWinds was infiltrated via its TeamCity build server, which traditional SCA tools did not scan. So how can you protect your software supply chain if you can’t see it? Don’t be haunted by SCA tools’ inability to scan the entire SDLC.

Vulnerable dependencies that impact your application can be found across the SDLC. You need to understand all development and deployment tooling–activity, settings, configuration, users and more–to protect your application. Pipeline composition analysis was designed from the ground up to understand your SDLC and bring context to your SCA findings to improve accuracy. It can give you complete visibility into the big picture to cut down on all the noise that traditional solutions generate.

Pipeline Composition Analysis: Put Your Nightmares to Rest

While it’s fun to be scared at Halloween, the last thing you want is to be terrified by your AppSec program. When the limitations of traditional SCA solutions threaten to keep you up at night, just remember that AppSec innovation requires the ability to do pipeline composition analysis across the entire SDLC, hence the shift from SCA to PCA. PCA plugs all the holes mentioned here, which hopefully can put even the worst nightmares to rest.

October 31, 2022
Cycode Expands Scope of AppDev Security Platform

At the Black Hat USA 2022 conference, Cycode this week announced it has added static application security testing (SAST) and container scanning capabilities to its software composition analysis (SCA) platform that is based on a graph database.

Amnon Even-Zohar, director of product management for Cycode, said the addition of these tools brings to eight the total number of modules that are now integrated with its Knowledge Graph database. Those modules address application security requirements spanning everything from infrastructure-as-code misconfigurations and DevOps pipelines to binary and source code analytics in a way that reduces both the number of false positives being surfaced, he added.

That approach makes it possible to provide more context to software remediation efforts by pulling data from across the entire software development life cycle rather than focusing solely on vulnerabilities found in source code, he noted. Cycode, for example, can pinpoint where vulnerable dependencies are found in test and production environments, said Even-Zohar.

A Cycode Pipeline Composition Analysis tool also provides insights into which components enable a vulnerability or security issue, how pipeline components relate to each other and if they are present in runtime environments, he added.

While there’s a lot of interest in implementing DevSecOps best practices in the wake of a series of high-profile AppSec breaches, many organizations still lack the tools required to secure an application development environment on an end-to-end basis. The Cycode platform leverages the data that already exists in DevOps workflows to enable organizations to better prioritize their remediation efforts and lower the total cost of doing so, said Even-Zohar.

The goal is to not only enable organizations to shift cybersecurity further left toward developers but also further right by more closely integrating cybersecurity and DevOps teams, he noted.

The DevSecOps challenge that most organizations are trying to navigate is that, historically, a list of vulnerabilities discovered by cybersecurity researchers is shared with DevOps teams without much context. Developers don’t know which vulnerabilities are most critical or, for that matter, whether the vulnerability identified is actually present within their application environment. SCA tools, in theory, could make it easier to identify, for example, where a Log4j or a shell vulnerability might be found. Graph-based tools take that capability to the next level by making it easier to visualize where any instance of a vulnerability might be found. In the absence of such tools, IT organizations would spend weeks looking for each instance of a vulnerability.

It may be a while before DevSecOps workflows become commonplace but at the very least there is now more awareness of software supply chain security issues. The Biden administration has also issued an executive order that requires federal agencies to review the security of software supply chains. Many enterprise IT organizations are now following suit. One way or another, application security is going to improve. The only thing that remains to be determined is what impact those improvements will have on the rate at which software can be built and deployed.

August 11, 2022