Ensure the Security of Your Software Supply Chain with Traceability
Security in modern software development goes beyond traditional perimeter defenses. Your organization faces new challenges in managing software supply chains. From component tracking to risk assessments, you need clear visibility into each code element that enters your systems.
This approach helps block unauthorized components from infiltrating the supply chain while validating that all software meets regulatory requirements. Through robust tracking and documentation, you can spot and fix potential problems, stay compliant, and protect your systems. Your business depends on knowing what code runs in your environment and where it comes from.
Software Supply Chain Visibility Through Component Tracking
When you build software, you rarely write everything from scratch. Instead, you take customer requirements and features they want, document those, and then figure out how to build the software. What you deliver to the customer will be a mixture of custom code written specifically to meet those requirements, along with pre-built components that handle general tasks like logging, error handling, data storage, security, and authentication. You combine these components with custom code to meet the customer's needs.
Understanding the Software Supply Chain
The software you deliver comes from various sources, such as open source, commercial components, or code your teams have written for other customers. Regardless of the sources, you are responsible for the security of that code when you deliver it to a customer. You need to have a good understanding of all the code, including:
- What requirements it satisfies
- How it works
- Where it is used
- How it has been changed
- How the components work together, as there could be strange side effects if they don't work together correctly
You also need to ensure that as data flows through the different software components, it is handled appropriately without opportunities for data leaks, security vulnerabilities, or breaches. After all, the data in your system is critical to your clients.
Regulated Industries and Complex Systems
Think about the software built for regulated industries like hospitals or banks. They have numerous systems that are not developed in-house, with a lot of commercial applications or customized commercial applications that combine custom code and commercial code components. They need to make sure that everything in their environment is independently tested, and that all the pieces put together by the systems integrator are complete, work together, and meet the user needs.
When dealing with complex systems that have different components, you need to make sure you understand how they work together from both a security and functionality standpoint.
Tracking Components and Traceability
The development teams will think about where they get their components from and make sure they are up to date. If there is a security vulnerability or a risky component that may have a vulnerability warning, they want to be able to track those components and push updates out to all the systems that use them. However, those changes, as well as fixing a security bug, might break something.
That's why it's important to understand the link (traceability) between a piece of code and all the requirements it meets. If you change code to resolve an issue, it might no longer meet the exact needs it was built for and could break the system.
If a security vulnerability affects multiple components, and those components have dependencies with other components, you need to be able to find out where else that affected component is being used and what other components it uses. This is another aspect of traceability - understanding all the different software components, how they fit together, where they are being used, and why.
Risk Assessment and Change Management
Before making changes and updating everything, it's important to do a risk assessment. Developers tend to be optimistic and think that fixing one vulnerability won't touch anything else, but QA professionals know otherwise. When you look at a particular change being made to fix an issue, there could be side effects. Fixing an issue might reduce functionality, while making a change to improve functionality could introduce a security issue.
Consider a healthcare environment. You need to make sure there are no HIPAA violations and that data is not being leaked. The same applies to banks following PCI DSS.
Here's an example: if a user requests functionality to improve the usability of the authentication and signup process, making it more intuitive could make it less secure because someone might now know why they were rejected.
Or let's say someone wants to change the logging component to log more information for audit purposes. That log might contain personal identifiable information (PII) or personal health information (PHI). If that sensitive information gets into the log file, it could leak out into another system, as happened with the log4j vulnerability.
In the aerospace industry, every time you make a change in any system, you need to understand the associated risk. It's a legal requirement for any aerospace onboard avionics platform or application. If a system has been changed, you need to make sure you understand where it has been used and if it has the potential to cause any flight safety issues.
Take the Boeing 737Max as an example. It infamously had a sensor with a single point of failure that was introduced as part of its MCAS system to correct a flight-handling issue, but it wasn't documented as such and lacked traceability to requirements. As a result, it wasn't spotted during testing that this system could potentially cause the plane's flight characteristics to change dramatically in a real situation, causing loss of life.
Compliance and Documentation
Maintaining a rigorous traceability program is important for security, but there's also a compliance aspect. Even if you are tracking all the information well, you generally have to meet with an auditor who will want to understand:
- Why a change was made and be able to trace it back to a customer requirement
- What code was changed and where
- If the code was reviewed
- If the code is actually in production, and if so, which other systems are using it
It's important to generate compliance documentation, and if you are using a system that helps manage traceability and all this information in a coherent whole, you can push a button to generate it as an output from your activities. If you are doing this manually or using ad hoc processes or spreadsheets, it can be very difficult to generate accurate documentation after the fact.
Industry Examples
There are many ways this manifests in different industries. In the pharmaceutical industry, companies have to prove that drug safety was taken into account and that the software used for requirements engineering and managing the clinical systems that handle the drugs are all compliant. They need to show there's no potential for unintended things getting into the medical device or pharmaceutical product and that everything has been measured correctly, including the clinical trial data and results.
In banking, if a transaction system goes down, billions of dollars can be lost in a second due to high volume transactions. Banks can also be fined by regulators for mishandling customer information or giving incorrect financial product advice. Understanding that your software requirements and deployed software match those requirements is key to avoid problems from both a functionality and compliance standpoint.
Security Beyond the Perimeter
From a security standpoint, it's even more important. If your software components are not well-defined and you can't tell where they are or which requirements they meet, how can you be sure that all the components in use are actually intended to be there? A bad actor could inject a component into your supply chain, such as a logging component or authentication system that looks benign but has been pushed as an update. Even if you didn't write the software and it seems innocuous, you need to track all the software that went into your system to ensure it is intended for purpose and wasn't nefariously injected.
Security is no longer just about securing the perimeter - it's also about looking at what's inside. It's like being the guardian of a castle, not only defending the gates but also examining all the supplies being brought in to make sure they are fit for purpose. You don’t want the king being poisoned because no one tested the food.
End-to-End Security Through Change Management
In highly regulated environments such as healthcare, finance, banking, aerospace, and automotive, meeting all the security and compliance needs of regulators is essential. Security is important for most IT systems, but in these industries, it carries a higher burden.
The Consequences of Compromised Security
If a bad actor compromises the security of a medical system, people could die from a medical overdose, receive the wrong drugs, or a medical device could fail. In banking and finance, people could be locked out of their life savings, which can be life-threatening if they are financially ruined. In aerospace and automotive, breaches in real-time systems could cause a plane or car to crash or behave unexpectedly. These sectors are high-value targets for cybersecurity threats, so organizations spend significant resources to prevent infiltration.
The Importance of Change Management
Traditionally, organizations focus on preventing unauthorized access to their systems through perimeter threats such as malware injection, firewall breaches, and phishing links. However, another critical aspect that is often overlooked is the daily changes made to the system. These changes can include:
- Software code updates to implement new features
- Configuration changes to security posture
- Infrastructure upgrades such as operating system or database version updates
While these activities are important, they can introduce vulnerabilities if not properly managed.
To ensure the security of the software supply chain, it is essential to have a detailed change tracking system that links changes back to specific features or requirements. Imagine if a notification from the change tracking system indicates that a login component was updated. You should be able to click on it and see the reason for the update, such as a vulnerability fix or a new feature implementation. This documentation provides confidence that the change was legitimately made for a valid reason. If someone upgrades a component without documentation, it may have come from a third-party repository where a malicious actor has attempted to inject code containing a vulnerability, backdoor, or trojan.
Change tracking is crucial for understanding what is in your system, and every change should be subject to risk management. There are risks associated with both implementing and not implementing a change, so a risk-based approach is essential. Every change has the potential to introduce a vulnerability or fix one.
Security Response Plan
In addition to documentation, a good process, and tools for change management, it is important to have a security response plan in place. This plan should enable quick identification, remediation, communication, and deployment of fixes into production if a bad component enters the system, whether accidentally or through a compromised third-party component.
Industry Best Practices
Best practices for end-to-end security through change management vary by industry.
In healthcare, clients typically maintain multiple versions of the system, including production, testing, and staging versions. They independently verify and test updates from vendors, especially when multiple vendors are building components that work together, before deploying them to production on their own schedule.
In the banking sector, customers often maintain color-coded versions of their systems, such as red, green, and blue. They test the latest fixes in development, promote them to staging, and then to production at their own pace. This approach avoids the risk of taking an unproven fix directly into production.
The aerospace industry has its own unique practices. Organizations may have the updated final production software air-gapped to prevent automatic pushes onto the platform. They take updates into a firmware device, independently test them, and then transfer them through the air gap onto the final system. This process prevents live updates from potentially introducing unexpected components directly into production.
By implementing a comprehensive change management process that includes detailed tracking, risk assessment, and a security response plan, organizations in highly regulated industries can ensure end-to-end security and maintain the integrity of their software supply chain. This approach helps prevent unauthorized changes, identify and remediate vulnerabilities, and maintain compliance with regulatory requirements.
Requirements Traceability in Regulated Industries
Requirements traceability is the process of mapping a system's features or requirements to their corresponding implementation, ensuring that everything is done correctly. When you have a new requirement, such as adding a patient screen on a healthcare application or a screen on a financial services insurance app that grabs customer information, you must map those functional requirements to all the relevant legal and compliance rules.
Varying Rules and Regulations
The rules and regulations vary by state and federal regulators, as well as by industry. For instance, if a legal rule states that you cannot ask someone for their social security number on a financial services banking application, then you cannot include that feature, even if a user or marketing person has requested it.
In the aerospace world, there are numerous standards around aviation from the Federal Aviation Administration (FAA) and the European Union Aviation Safety Agency (EASA), dictating what information, requirements, and tests need to be conducted. Just because someone wants to implement a new standard for a plane doesn't mean it can be done directly without proper verification.
Consider this: most modern planes still have cigarette ashtrays on bathroom doors, despite smoking being prohibited on flights. Removing this feature would require extensive retesting and compliance documentation, as it is specified in the regulations, even though it has no impact on the plane's flight capability.
Benefits of Traceability Analysis
Ensuring that requirements match the official legal standards is crucial for identifying any gaps between user requests and legal requirements. These compliance requirements are usually based on the law or exist for security or privacy reasons. Conducting traceability analysis offers several benefits:
- Identifying gaps ahead of time to avoid inadvertently adding bugs to the system
- Tying requirements to the software development process (coding, testing, etc.) to ensure no functionality is missing
- Avoiding rework by identifying missing functionality early on
- Documenting requirements thoroughly and linking them to all related code, tasks, and work for improved functionality, security, and operational excellence
- Identifying potential security holes by finding gaps between specified requirements and the actual implementation
Industry-Specific Examples
Let's take a look at some industry-specific examples of requirements traceability in action.
Banking
In the banking industry, requirements traceability is essential when implementing applications that transfer funds. Laws and requirements surrounding multi-currency and multi-regional transfers must be considered to avoid breaking any transfer rules or creating usability issues.
Imagine a user transfers money between accounts in different countries. There may be a 24-hour clearance period due to currency differences, which must be communicated to the user to avoid confusion.
Healthcare
In healthcare, requirements traceability is crucial when merging hospital networks and their respective systems. By mapping every feature in all the systems to the original requirements across both hospital networks, you can ensure that the consolidated systems will meet the needs of all patients and doctors in the new, larger network.
Aerospace
The aerospace industry presents the ultimate traceability challenge, with its complex physical supply chain involving multiple tiers of suppliers. Every company in the supply chain must work together and share information and requirements to ensure that all components, from nuts and bolts to software, meet the necessary performance characteristics and work seamlessly when assembled into the final system.
Traceability is essential for ensuring that each component meets the requirements and has the right performance characteristics, whether it's a physical part or software that must function in a real-time environment without any technical limitations.
Security Considerations
From a security standpoint, requirements traceability helps identify gaps that could potentially allow bad actors to inject unauthorized code or systems. If functionality is present that wasn't specified in the requirements, it may indicate that the system was overbuilt or that someone included unintended elements.
By maintaining a strong focus on security and traceability throughout the software supply chain, organizations can mitigate risks and ensure the integrity of their systems.
Multi-Location Security Management
As you increase the scale of operations, the challenge from a security standpoint only gets more complex. If you're running a single company in a single geography, perhaps a US or Canadian company working in one legal jurisdiction, it's easier. However, if you're working in a multi-location environment across multiple geographies, you're dealing with far more complexity in terms of different industry rules and security baselines.
Varying Regulations Across Industries and Geographies
Take banking regulations, for instance. They differ in the UK, US, and Europe. In healthcare, the US follows the FDA while Europe follows the EMA. If you're working in other industries like aerospace, the final regulator and set of rules may differ depending on whether the ultimate manufacturer is Airbus or Boeing. Additionally, you might be working with a supply chain that comprises manufacturers in other countries where the rules are different.
It's important to understand the variations between the companies that make up the organization and the rules in place. If you're a global company, are you following a global set of rules? Does each office, department, or factory have to follow its own set of rules? Are there potential gaps in security?
Differences in Security Baselines
In the US, it's common to follow SOC 2 Type II, while in Europe, ISO 27001 is more prevalent. They are both security baselines and frameworks but have differences. Should you try to do both? If you use one, what are the potential gaps between them? Are you going to be meeting your security needs in each country?
There's also the need for regional adaptability to meet local requirements and regulatory requirements that might be important in that country. Imagine you're building a product in one place, but it will be delivered to customers in different countries. Even though you might be physically located in one jurisdiction, the customers will be using it in different jurisdictions with different rules.
Consider this scenario: you're building a software product for a patient IT system that will be deployed in Europe, it will fall under GDPR. If it's going to be in the US, it will fall under HIPAA. They are quite similar data privacy rules but not identical, with differences in rules and requirements about what data can be shared.
Complexity in Meeting Security Needs
When dealing with this complex multi-environment, you're now dealing with far more complexity in terms of different standards. This means it's more difficult to potentially meet your security needs because the rules and requirements of those different countries are different. If you're trying to make sure you meet the highest security standard, it may be so complicated and difficult that you can't do that. You may have to have the same piece of software meet different security rules for different jurisdictions. There's a danger of missing something because you have to comply with different rules, standards, and geographies.
Requirements Traceability Approach
This is where a requirements traceability approach can help. If you're ultimately meeting the same set of requirements, the traceability between requirements, test requirements, development code, and components can help because that same requirement needs to be satisfied. Even if you've got two different security standards, they both have to tie back to the same ultimate requirement.
Let's say a requirement is that you have secure authentication or secure data masking of key patient information. That requirement can then link to particular implementations of that need in the different standards. You can make sure that regardless of whether you're following standard A or standard B, you have coverage of that requirement and won't miss anything.
Monitoring Performance and Compliance
Other things you could do to help include:
- Looking at industry standard metrics. Maybe in your country or industry, there are metrics that each different country has, and you can use those to understand if you're meeting your performance needs.
- When you start to implement the software in different countries and regions, check if you're meeting those needs.
- If you're going to be measured against different frameworks in different places, have a way to trace back to the different rules for each country and a per-country, per-industry, or per-geo dashboard.
The dashboard would show you that for country A, you have met 99.99% of all your compliance needs, while for country B or industry B, you've met 97% but are on track to increase that to 98% with three change requests.
It's important to make sure that if you are going to be monitoring your performance and understanding how much you comply with the requirements and the traceability between everything, you are accounting for local differences, variability, and regionality. You're not simply building it for one geography and then falling short somewhere else.
Common Challenges Across Industries
This is very common when you look at different industries. Hospital networks are increasingly becoming multinational. Banking and financial service institutions have long been multinational with lots of cross-border mergers. Even in the US across different state lines, it can be complicated.
In aerospace, there are two large commercial airline players, Boeing and Airbus, with giant supply chains that support businesses and industry across hundreds of countries, all working together on a single product. Now you've got the issue of standardizing the information and data, making sure you have all the different rules in place to meet the needs without compromising your security, which is incredibly difficult.
Securing Your Future with Advanced Software Solutions
Your software supply chain requires protection throughout development and deployment. Our Spira quality management platform includes best practices and templates that guide organizations through implementing traceability solutions that map requirements, code changes, and security controls from day one. In addition, our network of professional service partners bring deep expertise in healthcare, finance, aerospace and regulated industries where compliance standards matter most.
Ready to strengthen your software supply chain security? Our solution engineers will help you implement the right controls and processes for your organization. Contact us today to start the conversation about protecting your software assets, from the inside.