Skip to content

Dynamic Blog

How to Maintain System Integrity in the Supply Chain

The Most Insidious Form of Hacking

Supply chain attacks in the IT world have become more frequent in recent years and represent one of the most devious forms of hacking. Operators break into a manufacturer or developer’s network and hide malicious code within software updates and app source code before they’re released to the public, creating open doors that can later be exploited. Arguably the worst aspect of this trend is that it undermines confidence in a company’s digital signature, raising doubt and leaving users wondering whom they can trust.

The good news is that there are ways to protect against these intrusions, but actions must be preemptive, intentional and targeted to have any effect. The following mitigation approaches are based on the NIST Cybersecurity Framework.


Protecting the Supply Chain

The NIST framework begins with identification, which starts with asset management. Mapping the flow of both data and development within an organization is an absolute must, with specific attention paid to cataloging any point where external access is possible. With regard to software, developers must understand where and how it is updated throughout the supply chain. In essence, this is akin to identifying where the doors and windows are in your house. Until you’ve taken that step, you can’t evaluate the security of the locks.

A similar effort must be made to understand the business environment. In an era of globalization, no developer is an island unto itself. Identifying where external components (hardware or software) enter the supply chain permits prioritization of resources at targeted junctures where they can have the most consistent effect.

Once these are mapped, corporations should conduct in-depth risk assessment exercises to ensure that threat possibilities are well understood and can be effectively mitigated. This begins by working with other players in the supply chain and continues by assigning each external system a trustworthiness value that should be audited regularly to ensure its integrity. These evaluations should be continually bolstered by robust threat intelligence that’s gathered from government agencies, information-sharing forums and peers within the cybersecurity realm.

Remember that these processes are far from static: while they rest on a consistent framework, their individual applications must be dynamic and continuously evolving with the threat environment.

Proactive protocols should be created to outline what actions should be taken if a vulnerability is discovered.

Threat intelligence is a broad arena—so extensive, in fact, that issuing vague directives ordering cybersecurity personnel to watch for all threats negates its value and could introduce vulnerabilities. This is where the initial mapping efforts come into play, permitting security teams to outline priority intelligence requirements that facilitate deep diving in any potential risk areas.

The NIST framework outlines the protect and detect core functions next, which specifically focus on promoting the safety of software systems within the supply chain by identifying malicious code. One of the cornerstones of these functions is a thorough maintenance log, where all software upgrades and changes are recorded in detail. Any software integrity testing results should be documented to allow for retroactive analysis if a breach is discovered.

There are two primary ways in which this is accomplished, one reflecting upgrades or evolutions to existing products and another investigating new software. In the former scenario, maintaining old versions of software allows for side-by-side comparisons with new versions, narrowing the scope of investigation and highlighting any changes for rapid auditing processes. When new software is introduced, the initial investigation should be comprehensive and thorough, specifically targeting capabilities, permissions and indicators. Each aspect of the software should be critically analyzed by asking if the actions being performed are necessary to the application’s core functions. Anomalies should be marked and thoroughly vetted before any further exposure is permitted.


The Overall Process

One useful catchphrase in the era of globalization is to trust but verify.

Vulnerabilities cannot be eliminated; if we ever get to the point where we believe they are, the simple reality is that we’ve just deceived ourselves and are blind to where those weak areas exist.

Security begins by identifying likely and even potential areas for exposure, analyzing them thoroughly, then creating robust auditing protocols that are updated regularly with new threat intelligence. Approval cannot be relegated to the final step before it’s released to consumers but must be a living, breathing process that occurs throughout the development lifecycle. The framework must be rigid while its applications remain flexible. Adopting these standards goes a long way toward ensuring that our supply chains stay secure.

For information on how Dynamic can help with your supply chain technology needs, contact us at  866-399-1084 or



Proactive End-of-Life Management

The Key to Product Lifecycle Extension

To DOWNLOAD our EOL White Paper, submit the form below.