Securing Software Supply Chains Start by Empathy
Exploring the Operational Triad of Software Product Security - Developers, Business Teams, and Product Security Officers
Hello Cyber Builders ✋🏽
All companies are software producers concerned about the cybersecurity of their software. Let's take a closer look at how different functions in the company are impacted. Everyone has their perspective, and the views of other people in the company reflect the complexity of the subject. With more empathy for each person, we can understand them better and draw a path to improve software security.
I will focus on three main functions: developers and software engineers who create the software; the business side, whether it's the CEO of an SMB or the sales teams in a larger one; and the product security officer, if there is one.
The product security officer (PSO) collaborates with multiple teams and faces the challenge of dealing with technical heterogeneity and different testing practices. The business and sales teams must address detailed customer cybersecurity questionnaires and balance speed and efficiency with comprehensive security practices. Developers face pressure to deliver new features on time and within budget, and current vulnerability detection tools often lack precision and generate numerous alerts.
This post is part of a series:
🔗 **The Future of Cybersecurity: Everyone is a Software Producer.** As software takes command, a new cybersecurity battlefield - software product security and its supply chain
In this Post
You will find a comprehensive exploration of how different functions within companies interact and impact cybersecurity.
We start with software developers responsible for choosing software architecture and dependencies; our article highlights the challenges they face in detecting vulnerabilities, primarily due to inaccurate tools and a lack of integrated solutions.
Then, we continue with the role of the business end of companies, namely the CEO and sales team, to emphasize the importance of software security for their revenue goals and customer relations. These business personnel must answer detailed cybersecurity questionnaires from increasingly cautious customers, which may lead to tension between meeting customer demands quickly versus accurately demonstrating company security measures.
Finally, we discuss the role of Product Security Officers (PSOs) in large companies with high stakes, and an additional layer of security is required for products delivered to customers. They work with multiple teams with vast technical diversity, which adds complexity to standardizing tests and controls.
Each function has a distinct role that helps shape an organization’s cybersecurity landscape.
In the beginning, one creates software…
Let's start with the developer. They play a crucial role in ensuring product security. They are responsible for choosing the internal architecture of their software and selecting dependencies, including open-source libraries. Additionally, they establish coding rules for their software.
The developer is indeed a key person in this matter. Recently, numerous solutions have emerged to assist development teams in detecting vulnerabilities in their software. These solutions encompass static source code analysis, open-source dependencies analysis, and CI/CD production chain monitoring.
These tools provide developers with valuable information, enabling them to identify vulnerabilities or receive alerts. The best solutions seamlessly integrate with the development environment, allowing development teams to access security information within their IDE without disrupting their existing CI/CD chain practices.
This article could end here if everything were going great in the best of worlds! Unfortunately, this takes things out of context and lacks empathy for the software engineering practices.
First, these developers face significant pressure to deliver new features on time and budget. They are asked to deliver MORE code, not to remove dead code or revamp software parts that contain vulnerabilities. Discussions on security with their product manager or sales colleagues require a delicate approach, as security is essential but always seen as an uncertain threat. Additionally, discussing the viability of a new feature, which could lead to short-term business success, is never easy.
However, the problem continues. The currently available tools suffer from a critical flaw: they lack precision and accuracy. These tools generate numerous alerts that often lack meaning and value. Instead of verifying the validity of each alert, these tools tend to create alerts without the necessary means and technology. As a result, they are unreliable.
I have managed development teams throughout my career. Regardless of the technology or the scanner, the same conversation always comes up.
Me: Oh, look, ScannerX tells us there are 50 vulnerabilities in the software, and 20 third-party libraries we use also have vulnerabilities. You should take a look; I would like us to prioritize this for our next cycle.
Developers: OK, we will have a look and do our best efforts.
A week later, the teams came back.
Developers: we looked at the first ten alerts, which were all false. And as for the libraries, we don't use the vulnerable code. ScannerX is using names and version numbers, but it is not accurate.
Me: Ok…..
This little story is repeated very often and discourages the teams. It goes like this: when tools are implemented, they tend to be poorly configured due to a lack of time and resources. Moreover, there is no magic wand that would be 100% accurate. Consequently, the results they produce are often not thoroughly analyzed by anyone. This can lead to missed opportunities for improvement and hinder the teams' overall progress.
…and one sell it!
Other positions in the company include business, sales, and marketing. The company's management and business division are interested in increasing revenue, turnover, and sales using the same solution.
Everyone today is deeply concerned about the cybersecurity of their software. The top and tier 1 companies have successfully distinguished themselves through their software, solutions, and integration into their industrial-connected objects. They have effectively connected with their customers through software. (See Everyone is a Software Producer)
These customers increasingly demand that their suppliers demonstrate that the software they buy integrates no flaws, bugs, or security issues. They understand zero risk is not achievable, but they want to know the quality and security assurance practices in place.
Nowadays, many procurement processes include detailed questionnaires regarding cybersecurity and the overall IT practices of their suppliers.
Nowadays, many procurement processes include detailed questionnaires regarding cybersecurity and the overall IT practices of their suppliers. These questionnaires probe into various aspects, such as access management and rights to source code or digital signatures of the software shipped on the supplier's behalf.
They want to know how the supplier is decommissioning user accounts or servers or organizing peer reviews, monthly security management reviews, and annual reviews with the company's management on security objectives.
In short, mature enterprise buyers today want comprehensive insights into how cybersecurity is implemented within their suppliers. Certifications like ISO 27000, SOC, or ISO 15408 Common Criteria can enhance these discussions, as they require companies to document their practices. However, mature buyers know that the certification scope is always partial, so they keep adding questions to the security questionnaire.
Latent conflict between business and security
From a business and sales perspective, the primary focus is being responsive and agile in addressing customer inquiries and concerns. The goal is to reduce doubts in the buying process and ensure a smooth transaction. However, it's essential to acknowledge that cybersecurity is a nuanced and precise practice that cannot guarantee 100% perfection. It involves comprehensive measures to identify vulnerabilities and implement appropriate controls. While the business aims for speed and efficiency, security practices require careful analysis and implementation.
From a sales perspective, these questionnaires can sometimes be seen as obstacles to conducting business. The questionnaire respondents must have the authority to answer such inquiries, and it should be the CTO or the CISO (Chief Information Security Officer), resulting in delays and uncertainty.
On the other hand, software and security engineers responsible for answering the questionnaires will provide honest responses, describing the existing measures and any areas that need improvement. Identifying vulnerabilities rather than receiving a simple "yes” to all questions is more valuable and informative. They must demonstrate that their company has implemented the policies and controls their customers require. Having proper documentation and, ideally, a trusted third-party audit and inspection of implementation is probably the best case. Even better, if they issue a label or a certification.
Naturally, this dynamic can create tensions between the sales and technical security functions. Selling a “perfectly secure” solution would be easier, even if it does not exist.
Which leads to a new corporate role: Product Security Officer
When the stakes are high, large enterprises have created the role of the Product Security Officer.
You are probably familiar with the CISO (Chief Information Security Officer) and his teams responsible for risk management, the SOC (Security Operations Center), incident response, and threat intelligence. All these functions are known and implemented today in terms of cybersecurity. However, the CISO organization often only focuses on the company's internal network and systems, its IT systems. When we look at “software product security,” we discuss the security of what is shipped to the customer, the products, and the software part.
For an aviation company, it is about securing its planes or the software that goes into them. In the automotive industry, it is about securing the cars and the electronic systems that go into them. For small companies, these two roles are probably merged. Still, for larger ones, the Product Security Officer is a separate role that works closely with engineering teams and collaborates with them to implement best practices.
So, what are the challenges for our PSOs?
👉🏼 Product security officers are primarily found in large, well-structured companies with significant stakes. These leaders play a crucial role as their software often controls the physical world and can have real and physical consequences.
In automotive, telecommunications, and robotics industries, where precision and safety are paramount, product security is essential to ensure the smooth and secure functioning of the systems and technologies involved.
They are a support function aiming to improve and attest to the level of security of the company's products and generally deal with multiple teams to deliver a product. In these environments, it is not uncommon to have an engineering team for the hardware layer, one for the embedded software layer, one for the web administration interface, and probably another for the cloud system that orchestrates multiple hardware components. Each team is associated with a different technology stack and different project management. This is also the case in very large companies or service companies that have been built through acquisitions and where, by nature, the underlying software components are all different. This technical heterogeneity is a problem for our Product Security Officers, as another heterogeneity of the tests and controls performed compounds it.
Since the teams are heterogeneous, they have developed the habit of conducting different types of verification: Source code analysis, functional testing, dynamic scanning in test environments, penetration testing in the production environment, and threat modeling.
All these practices occur simultaneously and asynchronously across all teams. Establishing a strategy means choosing which practices the organization will rely on.
Conclusion
In conclusion, the collaborative interplay between Developers, Business leaders, and Product Security Officers plays a significant role in shaping an organization's cybersecurity landscape. Each brings a unique perspective, fostering a well-rounded approach to security based on shared knowledge and experience.
As the world becomes more digitally interconnected, all stakeholders must understand their role in upholding security measures. Remember - cybersecurity is not the sole responsibility of one individual or department. It requires a comprehensive, company-wide effort that places system vulnerability at the forefront of priorities.
Goodbye Cyber Builders! Don't forget to share this article with other cybersecurity enthusiasts and professionals. Let's grow our community and knowledge together! Questions, thoughts? Join the conversation below or reach us at cyberbuilders(at)substack(dot)com. Your input is valuable!
Laurent 💚