Cybersecurity is a complex process that should be involved at every step of the development lifecycle. Development teams often mistakenly assume that security should begin and end with their development. It is important to address security at the earliest possible phases to ensure nothing is overlooked. This includes concerns in the supply chain, which may easily be missed.
Concerns In Supplier Services
Systems are often very complex, at times even overly so. Different tools for payment processing, project management, CI/CD pipeline management, version control, and just about anything else can be integrated into a system. This extended functionality increases efficiency and massively cuts down on the time it takes to integrate certain processes. Development teams can take their focus away from these areas and apply it to other, more complex areas that they are developing from the ground up.
Typically, teams have little control over what is happening behind the scenes with these integrated systems or processes. They will ultimately have to rely on the service provider to implement any functionality, changes, or security. While this provides the advantage of development teams not needing to worry about exactly what is happening with those components, it can take certain things out of their control to a negative effect.
Teams will have to place their full trust in the security of these integrations. There can be sensitive information and proprietary data passing through these systems. When this is the case, a compromise can be catastrophic. A very common integration is for payment processing systems. These can be difficult and costly to implement, so it is very frequently outsourced to a service provider that specializes in that area. Another example could be data storage and management, which often will contain PII or PHI.
Aside from customer data being breached, which is detrimental to the development team and the service provider, another major concern is the protection of intellectual property. A perfect example of this would be a version control system that stores and manages a team’s source code. If this were to be breached and a threat actor was able to access proprietary source code, they could be able to wreak havoc on the system with this elevated knowledge of the system they are attacking.
Any time a team is assessing a new integration, there should be internal discussions about what the implications could be in the event of a security incident against that integration. Teams should understand any information that the integration will have access to and do an analysis of what the impact would be in the event of a problem. It can be a good idea to meet with the provider and review their security practices. Teams should make sure that providers are adequately following best practices, such as getting regular penetration testing.
Concerns In 3rd Party Libraries
Addressing more specific functionality in the flow and design of a system, it is very common for developers to use 3rd party libraries in their code base. This has a great advantage in the fact that developers do not have to write code that has already been written. The downsides come in similar ways to other external integrations, where teams will have limited control over security and functionality. One area where 3rd party libraries differ is that many of these are open-source projects. If this is the case, developers can often create their own forks of the project with specific changes, or contribute to the master branch of the code base searching for approval of their changes.
Open-source projects often have far less stringent security requirements. Developers cannot be expected to adhere to certain security practices when these projects are meant to be open source, often passion projects. There are a staggering number of third-party components available that meet a myriad of requirements. Similar packages produced in entirely different ways can provide similar results.
Development teams should carefully consider any package that they plan on integrating into their codebase. A review of the package is very important. Developers should never integrate a component without having a clear understanding of everything that is being done with that package. Any system should be scanned for known vulnerabilities through a tool that tracks publicly available CVEs.
If problems are identified, developers can create their own forks and implement their own security controls. Inversely, if developers are making functional changes to an already secure package, they should carefully evaluate the custom changes to make sure they are not introducing any new vulnerabilities. All of this should be done as a continuous process integrated into the standard CI/CD pipeline.
