devopsy.kinsta.cloud

Category: IT Security

How DevSecOps Addresses Supply Chain Security

“The absence of security in the initial stages of system engineering is the single most significant cybersecurity gap and risk in modern system development.” This quote from tech entrepreneur Linda Rawson is a good reminder for the current cybersecurity threat situation. With software supply chain attacks increasing in aggressiveness and sophistication, organizations need to understand that cybersecurity should no longer be an additional process, let alone an afterthought.

Integrating security in the software development process provides a few other benefits, including better efficiency and customer satisfaction. However, its most notable benefit is addressing cybersecurity threats more effectively compared to the conventional ways of enabling software security.

The Rise of DevSecOps

DevSecOps is a fast-rising star in today’s search for effective cybersecurity solutions. The DevSecOps market is expected to be worth $23.63 billion in 2030, growing at a CAGR of 23.84% in the forecast period 2023-2030. Its value in 2022 was estimated at around $4.27 billion.

This double-digit growth is actually a bit conservative. Other forecasts showed higher CAGRs in the 30% range. This growth hints at the strong demand for DevSecOps solutions. Many organizations have started to acknowledge the benefits of implementing security validation methods early in the software development life cycle (SDLC) instead of doing them in bulk as a separate phase at the end of the development process.

Many organizations are now convinced that they can benefit from shifting left or bringing security into the SDLC earlier. Tools and solutions like static code analysis (SCA), automated dynamic analysis, interactive application security testing (IAST) and source composition analysis address security weaknesses before an application is released to the market. This allows organizations to release apps faster and, because of the elimination of most bugs and vulnerabilities, provide considerably better user experiences.

Vulnerabilities will never be completely eliminated, but they can be significantly reduced and more properly resolved while software is being developed if security validation is integrated in the development process. Some software defects and weaknesses tend to be more difficult to address through a separate security testing process, since it would entail a broader code tracing or review as opposed to quickly spotting the affected code when security validation is done alongside the development process.

Addressing Software Supply Chain Attacks

So, how does DevSecOps help prevent supply chain attacks? The key is in the visibility and control DevSecOps affords.

DevSecOps requires vigilance of security issues throughout the software development process. Security is not relegated to a different team that doesn’t understand the specifics of a development project. As such, the team has broad visibility over security concerns. Because the DevSecOps team also has mastery of the code being developed, it is easy to trace the origin of vulnerabilities and implement the necessary corrections.

DevSecOps is aided by automated tools that scan code for security issues and detect threats even before they manifest themselves as problems. These tools are used across all phases of the development process, from the time code bears basic features and functions to deployment and post-production.

Static testing: Even before an application’s code is ready to run, it can be subjected to static testing to find vulnerabilities. Tools such as static application security testing (SAST) can analyze code and detect possible security problems.

How does this address software supply chain attacks? Static testing can be overlaid on automated CI/CD pipelines to stop code that has security weaknesses from getting committed to the codebase.

Dynamic testing: An automated dynamic analysis can be used for code that is already executable. This is done through dynamic application security testing (DAST) tools, which are capable of detecting vulnerabilities usually invisible to SAST but which are detectable once the code is running.

How does this address software supply chain attacks? Organizations can implement automated black-box testing for apps in the CI/CD pipeline(s) to detect security flaws for apps that are already executable. This addresses the vulnerabilities that have not been detected by static testing while reducing the costs associated with the corresponding remediation.

Interactive app testing: This is a combination of static and dynamic testing. It employs IAST tools which run static testing on available code and come up with bespoke dynamic tests for a specific app to identify issues more thoroughly.

How does this address software supply chain attacks? Pure static and dynamic testing usually apply to earlier stages of the development process, whereas interactive testing addresses vulnerabilities that emerge in the later parts. By bringing IAST to the CI/CD pipeline, organizations achieve better security issue detection outcomes, which means the prevention of malicious code deployment.

Supply chain analysis: This entails the use of tools that specifically examine the security of third-party libraries and dependencies. To be clear, this is not the only method for addressing software supply chain vulnerabilities. In this case, supply chain merely refers to the external libraries, dependencies and other components that do not originate from the development team.

How does this address software supply chain attacks? Integrating software chain analysis tools in the CI/CD pipeline significantly reduces the adverse effects of vulnerabilities in dependencies and other components on a project’s codebase as well as on the development process itself.

Security-as-Code

One of the best practices developed in line with the integration of security in the software development process is the idea of implementing security-as-code. This means that security policies and measures such as testing and validation are turned into code whenever possible. In other words, the code itself already bears security mechanisms. Security testing runs automatically whenever code is committed. This ensures robust, consistent, highly scalable security that does not rely on external rules and mechanisms to prevent the introduction of anomalous code or malicious inputs.

Security-as-code also means that the DevSecOps team can see how modifications to code and the underlying infrastructure are created. The team can map out the impact of code changes and identify the areas where security tests and regulations can be implemented to optimize processes and avoid unnecessary delays.

Security-as-code is essentially the automation of security practices. It is not applicable in all instances, though, so it is still important to be knowledgeable about security testing methods that can be used in different stages of the development process.

Securing the Software Supply Chain

The SUNBURST incident and other similar high-profile attacks should serve as a warning for all organizations to ascertain the security of their software supply chain. DevSecOps is one of the best solutions right now. It does not guarantee the complete elimination of all threats, but it ensures that if threat actors succeed in getting around security controls, a breach won’t go unnoticed.

May 3, 2023
Codenotary Previews Secure SBOM Creation Service

Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

April 27, 2023
Report: Most IT Teams Can’t Fix Open Source Software Security

Lineaje, a provider of a platform for securing software supply chains, today published an analysis of 41,989 open source components embedded in the top 44 popular projects managed by the Apache Software Foundation (ASF). That analysis found more than a quarter (26%) of vulnerabilities are not patchable by the application development team that deployed them.

In addition, the report found that 64% of the vulnerabilities analyzed have no patch as of yet. Overall, 68% of the vulnerabilities analyzed are due to dependencies created when an open source software project included a component or package developed by another open source project maintainer.

Lineaje CEO Javed Hasan said that means that 90% of open source dependencies are transitive, in the sense that they are created when maintainers of a project included a vulnerable open source component created by another entity. Only 10% of the vulnerabilities discovered by Lineaje are the result of a dependency that an application development team could actually address on their own, he added.

Overall, the report found a full 82% of components that are relied on to build open source software are inherently risky due to vulnerabilities, security issues, code quality or maintainability concerns. In addition, 5% of components failed a basic integrity check, with 3% having no known origin.

Open source software is not created equal no matter what consortium is overseeing its development, noted Hasan. Unfortunately, there is no universally accepted method for validating the integrity of open source software, so application development teams should proceed with caution whenever employing open source software, he said.

The challenge, of course, is that developers have been reusing open source software within applications for years now. It’s only in the recent wake of breaches involving open source software that organizations have been taking a harder look at how applications are developed.

The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is now at the forefront of an effort to better secure open source software by focusing on 10 streams of investment that, in total, will require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure open source software is secure when deployed in a production environment belongs to the organization that deploys it.

Hopefully, following a recent executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead—assuming, of course, the organizations that rely heavily on open source software make more substantive contributions to securing it. In the meantime, organizations can count on the fact that cybercriminals have taken note of the vulnerabilities in applications that can be traced back to flaws in a wide range of open source software.

April 17, 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
Endor Labs Taps ChatGPT to Identify Secure Open Source Software

Endor Labs has launched DroidGPT, an extension of its software for assessing risks in open source code. DroidGPT integrates the ChatGPT generative artificial intelligence (AI) platform to make it simpler to discover the most secure version of an open source package.

That capability makes it possible for developers to launch a natural language query from within the Endor Labs platform that asks ChatGPT to identify, for example, the most secure logging modules of Java applications.

Endor Labs CEO Varun Badhwar said the goal is to make it simpler to apply guardrails to application development processes that today rely heavily on reusing open source packages. Developers often wind up using an older version of those packages that are not as secure because a known vulnerability has not been remediated.

Endor Labs’ Dependency Lifecycle Management platform applies graph analysis to identify the depth of dependencies that exist within an application. That capability makes it simpler to identify where vulnerable components have actually been employed within an application. DroidGPT extends that capability to identify the most secure versions of those components that developers should be using, said Badhwar.

Having a full understanding of their dependency graph also lets customers generate and analyze accurate software bills of materials (SBOMs) as applications are dynamically updated, noted Badhwar.

The level of dependency on open source software packages to create applications has risen sharply over the years. An analysis of nearly 2,000 software packages published by Endor Labs found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer used an open source component. Functional dependencies are created whenever developers download a third-party component, so it is crucial to assess the risk levels created by those dependencies.

Fortunately, in the wake of a series of high-profile breaches, there has been increased focus on securing software supply chains. The ongoing challenge is most developers don’t have a lot of cybersecurity expertise, so as contributions are made to open source projects it’s relatively easy for mistakes to be made. The simple truth is many applications deployed in production environments are riddled with known vulnerabilities that have yet to be addressed. DroidGPT is designed to make it simpler to begin the process of remediating software vulnerabilities in applications as they are built and after they are deployed.

There is no doubt that it will take years before organizations are able to implement a set of truly mature DevSecOps best practices to teach developers how to build more secure applications. That journey, however, needs to begin with tools that enable them to address fundamental issues that dependencies inevitably create. After all, the best way to combat application vulnerabilities is to make sure they don’t manifest themselves in code in the first place. Making it easier to update applications using older versions of open source modules is nothing less than critical at a time when cybercriminals are getting more adept at exploiting them.

April 14, 2023
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Monster.com

SnapLogic
San Mateo, California
Infrastructure Engineer
$183,310

LinkedIn

Metropolitan Transit Authority – NYC
New York, New York
Cybersecurity Officer – DevSecOp/Cloud Infrastructure
$144,500 to $191,000

Dice.com

Flexion
Remote
Azure DevOps Engineer
$140,000 to $170,000

Indeed.com

Woven Teams
Remote
DevOps Engineer
$116,000 to $147,000

SimplyHired.com

Raytheon Missile and Defense
Schriever Air Force Base, Colorado
Senior Software Engineer
$75,000 to $161,000

April 10, 2023
Synopsys Preps Extensions to Polaris SaaS Platform

Synopsys plans to extend the capabilities of its Polaris Software Integrity Platform for securing application development environments by adding dynamic application security testing (DAST) tools along with the ability to scan code used to provision infrastructure.

As a software-as-a-service (SaaS) platform, the Polaris Software Integrity Platform was created by combining the static application security testing (SAST) tool Synopsys gained with the acquisition of Coverity in 2014 and the software composition analysis (SCA) tool it added to its portfolio by acquiring Black Duck Software in 2017.

In 2015, Synopsys acquired the Seeker tool for analyzing the code created using interactive application security testing (IAST) tools from Quotium. The company last year acquired WhiteHat Security from NTT to add a DAST tool.

Patrick Carey, senior director for marketing strategy for Synopsys, said that the company would add the capabilities of those latter two platforms to create a comprehensive set of best-in-class security tools that are easily accessible via a SaaS platform.

At a time when more organizations than ever are moving to secure software supply chains, Carey said it’s critical to provide developers with more visibility into vulnerabilities across the entire software development life cycle (SDLC). Some organizations are opting to achieve that goal by embedding tools within the SDLC themselves, but many organizations would likely prefer to invoke a SaaS platform that they don’t have to maintain, noted Carey.

He noted that a SaaS platform makes it simpler to point a collection of integrated tools at a code repository to surface those vulnerabilities.

As DevSecOps workflows continue to evolve and mature, more responsibility for application security is shifted left toward developers. The challenge is that many developers have limited cybersecurity expertise, so it’s critical that they have access to high-quality security tools.

In addition, a SaaS platform helps reduce the total cost of achieving that goal by providing multiple capabilities within a single integrated platform, said Carey.

Naturally, most of the focus today is on reducing the number of vulnerabilities that find their way into production environments as applications are being built. However, there are already large numbers of unaddressed vulnerabilities in applications that have already been deployed. Organizations will need to find ways to address that technical debt in addition to providing developers with tools that help prevent those code vulnerabilities in the first place.

As such, there is no one central place through which application security can be managed, noted Carey. Instead, application security needs to be addressed across every phase of the SDLC, he added.

It’s not clear how quickly organizations are adopting DevSecOps best practices, but as calls for increased liability for software development increase—as outlined, for example, in the U.S. National Cybersecurity Strategy— organizations should expect DevSecOps workflows to become a requirement. Otherwise, organizations will be severely penalized for vulnerabilities that find their way into code. In effect, there is now a race to embrace DevSecOps before any proposed liability legislation becomes the law of the land.

April 6, 2023
A Seven Point Checklist for Getting SAST Right

With so many physical products—from automobiles to airplanes and medical devices to industrial control systems—now being driven by software, product security has become a top-level concern for manufacturers. Software flaws can not only affect security by introducing vulnerabilities that can be exploited by attackers but also impact safety by compromising a product’s functional operation.

In addition, product security has significant financial implications. For example, fixing a vulnerability in development costs 10 times less than in testing and 100 times less than fixing it in production. This explains why static application security testing (SAST) has become a cornerstone of product security and the engine for implementing code analysis at the earliest stages of development, commonly known as shift left security.

Unlike other forms of application security testing (AST), SAST scans 100% of the code, including configuration files, not just the code that is executed at runtime. SAST can also provide additional benefits, such as quality and architectural testing. Software quality and security are inextricably linked since poorly written software typically is insecure software.

With the stakes so high, getting SAST right is the tipping point for any product security program. To evaluate SAST tools, consider the following checklist to make sure they align with your business requirements:

1. Deep Language Support: C/C++, Java, C#, etc.

Languages are often selected based on the programmatic requirements of the software producer, the needs of the consumer and the hardware associated with the product. For example, developing software for safety-critical applications like aerospace requires different capabilities than languages used to build web applications.

2. Compiler and Embedded OS Platform Compatibility

Compilers used for embedded software development implement unique flags for configuration, such as performance optimizations, code size, error checking and the diagnostic information emitted. Since embedded OS platforms typically include compiler and debugging tools plus the various OS files and configuration options, make sure the SAST tool can integrate with the development environment used.

3. Actionable Alerts

For the DevOps team to embrace security, embedding security in the software factory life cycle cannot slow down development velocity or hinder developers’ ability to meet software release timelines. False positives redirect developer attention away from writing software to investigating potential defects. Too many false positives result in developers losing faith in true positives and paying less attention to security alerts of real substance.

4. Built-In DevOps Integration

The software development life cycle employs an extensive toolset that provides automation to help developers get products to the production stage faster—not unlike a manufacturing plant or factory. Make sure the SAST tool supports and integrates with distinct tool categories including collaboration and management, source control and repositories, IDEs, compilers, orchestration and automation and business intelligence.

5. Flexible Deployment

Depending on the organization and industry, SAST may need to support a variety of deployment options, including on-premises, cloud, hybrid, etc. For example, air-gapped deployments are often required in security-sensitive environments where the data protection uncertainty associated with multitenant public clouds is unacceptable. Meanwhile, cloud-based SAST can provide benefits like scalability and elasticity and reduce infrastructure capital investments.

6. Developer-friendly UI

Shift left security is accomplished by integrating security warnings into the integrated development environment (IDE) used by engineers. A SAST tool that works within existing IDEs can reduce the number of errors presented to testers, which subsequently reduces the volume of kickbacks to engineering and leads to faster time-to-market.

7. Standards

Many organizations use—and some must comply with—standards for software coding best practices such as SEI CERT, MISRA, etc., which provide a framework for improving the safety, reliability and security of software systems. In addition, a company may need to satisfy functional safety standards such ISE 61508, as well as derivative industry specific standards including IEC 62304 (Medical), ISO 26262 (Automotive), DO-178C (Avionics) and IEC 62434 (Security). A SAST tool should provide integration with key standards that govern an organization’s products and, where appropriate, be certified for them.

Using these guidelines for evaluating SAST tools will help ensure that the product you select meets your organization’s business, technology, safety and security requirements.

March 24, 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
Awareness of Software Supply Chain Security Issues Improves

A global survey of 167 software professionals suggested that, while there is a lot more awareness of application security issues, the adoption of DevSecOps best practices is still not pervasive.

The survey, conducted by Chainguard, the Eclipse Foundation, the Rust Foundation and the Open Source Security Foundation (OpenSSF), found that just over half (51%) of respondents are either concerned or are extremely concerned about software supply chain security.

In addition, only a third of respondents (33%) reported they are familiar with the Supply-chain Levels for Software Artifacts (SLSA) framework for building more secure applications. Well over a third (36%), however, said they had never heard of it.

Only a quarter of respondents (25%) reported that their team always signed built artifacts, the survey found.

The survey identified the most challenging issues developers are encountering and found they are reproducing builds (64%) followed by creating hermetic builds that are isolated from other software libraries (62%).

Mikaël Barbero, head of cybersecurity for the Eclipse Foundation, said while awareness of software supply chain issues is higher, it’s apparent that other priorities are still getting in the way of adoption of DevSecOps best practices. For example, software bills of materials (SBOMs) may generate a lot of headlines, but their adoption remains mixed, he added.

John Speed Meyers, a security data scientist for Chainguard, noted that incentives still need to change; too many managers that hire developers still emphasize performance and delivery times over application security. Many developers, as a result, still tend to view cybersecurity as an obstacle to be overcome or worked around rather than a core capability that they will be graded on, he added.

In theory, as responsibility for application security shifts left toward developers, overall cybersecurity will improve. Most developers, however, have little to no cybersecurity training, so the odds they will be able to resolve these issues are low. Instead, many organizations are either trying to embed cybersecurity professionals within DevOps workflows or, at the very least, deputize at least one developer to advocate for cybersecurity within those teams.

Regardless of commitment level, it’s apparent that organizations need to address everything from locking down developer environments to thwart phishing attacks to ensuring application builds are not inadvertently infected with malware. The challenge organizations face is both technical and cultural, so the amount of effort required should not be underestimated.

In the meantime, organizations should expect to see cybercriminals increase their attempts to compromise software supply chains. Infecting malware into software components that will be used by multiple downstream applications is, from their perspective, one of the most efficient means of wreaking havoc. Right now, organizations make it too easy for cybercriminals to compromise application environments.

Organizations should also recognize that tolerance for insecure applications is also declining, as evidenced by the National Cybersecurity Strategy put forward by the Biden administration. It’s not so much a question of whether organizations that create software will be held liable for application security issues as much as it is to what degree.

March 21, 2023