In a candid conversation with OSFY’s Yashasvini Razdan, Martin Callinan director, and Prashant Singh Baghel, senior consultant at Source Code Control emphasised aligning open source practices with overall business strategies. They flagged it as a critical business concern, urging proactive handling of compliance issues tied to open source components in software.
Q. What is Source Code Control all about?
M: Source Code Control, as the name suggests, helps companies that develop or produce software, to manage and control software supply chain risks and be able to demonstrate the quality of the software they produce. The risks we target aretwofold one associated with intellectual property, and risks associated with security vulnerability in components and libraries. If there is intellectual property value in the software being developed for a device, a cloud service, or delivered software, there is a chance that some of the libraries and components developers integrate into the code may pose risks. We specialise in helping companies implement tools and processes to both mitigate those risks and be able to demonstrate to customers, prospects and partners they are not passing these risks on to them.. Another concern is that a developer might inadvertently include a component with a vulnerability. If the software is shipped or the service is delivered with such a vulnerability, it could be exploited, potentially affecting customer conversion.
We also help organisations acquiring software solutions to implement strategies to benchmark suppliers and their ability to manage IP and security risks in the software they are supplying.
Q. If a CIO or a CTO asks you the same question, how would you answer that?
M: I would respond in the same way. CIOs/CTOs face the pressure of having to deliver the software and its newer versions to customers, but there is a perception that if they spend time trying to identify risks, they wouldn’t be able to deliver the software on time. This is where we help automate the controls that allow developers to be creative while giving them guidance on how to avoid risks. Until recently there were no standards or best practices to help guide software companies to manage supply chain risks. but over the past two years industry regulations have been set up and customers are more aware of the compliance issues in software applications. With the use of open source for software development, they ask questions, which will eventually come to the CIO/CTO, who’d need to be transparent about what’s in the software. If they can’t answer that question, they might not bring the business
P: Developers are focussed on creativity and the development of the software rather than the compliance. It’s the CIOs and CTOs who have to prioritise the focus towards compliance, and create awareness about the same, which is what we are seeing in the market, as the executives understand that open source compliance is the need of the hour.
Q. What is the significance of open source for Source Code Control?
M: Industry statistics indicate that up to 90% of modern software is composed of open source components libraries and frameworks. This demonstrated the value of open source to aid and speed up software development but from our experience very few companies developing software can identify as open source companies, leading them to overlook the need for open source management. This oversight poses a hidden risk, potentially delivering software to customers that puts them at risk. Open source software is crucial for software development, enabling the efficient reuse of code instead of starting from scratch. Without open source, every company developing an app would need to recode basic elements like buttons, icons, and text input. With open source, these components can be readily incorporated into new code, streamlining development. The term “open source” carries different meanings depending on the licence. Over 2,000 variants of open source licences with distinct obligations have been documented. The specific licence determines whether sharing the source code is required or if attribution will suffice. Understanding these differences is crucial for mitigating various risks for commercial companies, which is where we specialise.
P: When it comes to open source, there is a prevailing misconception that it’s free. There is a cost associated with it that most people don’t understand, which can later cost you a lot of money, sometimes through lawsuits as well. This is where we also come in to explain how to have certain checks in place while using open source to ensure that you are abiding by certain obligations and avoid falling into any particular legal or compliance issues.
Q. How would you explain your basic business model?
M: At the beginning, it’s about business risk. We talk to CEOs, CTOs, CIOs about the business impact of not managing compliance when using open source. Developers are focused on development and might not engage in business discussions. At the business level, understanding the impact of a security breach, including reputation damage and compensation costs, is crucial. We act as an interface, educating management on potential risks and solutions. Additionally, we work with development teams to implement risk mitigation strategies. Another aspect is demonstrating software quality to customers. The Open Chain project, hosted by the Linux Foundation, has authored an ISO standard (ISO 5230) outlining processes for ensuring software quality in the supply chain. We assist companies in adopting this standard, emphasising trust-building in the software supply chain. This standard becomes a competitive advantage when bidding for business, demonstrating a commitment to delivering secure and quality software.
Unravelling the compliance puzzle
Q. How are you advising your clients or prospective potential customers regarding open-source compliance?
P: When utilising open source, we categorise it into three fundamental risks: operational risk, licensing risk, and vulnerability risk. In the IT domain, especially in cybersecurity, vulnerability risks are paramount, drawing significant attention. However, licensing and operational aspects are often sidelined. Our approach involves consolidating all these aspects, emphasising the need to consider them collectively. Vulnerabilities, though visible upfront, are not the sole focus; equal awareness should extend to licensing issues that could lead to long-term damage. Looking into your code today is crucial, as issues may arise even after five years, with potential changes in development teams. We try to encompass and comprehensively address all open source-related risks and present them to our customers.
Q. What do you mean by “encompassing and addressing all open source-related risks”?
P: Multiple tools are available in the market, each focusing on different aspects. Some concentrate on vulnerabilities, others specialise in Vulnerability Assessment and Penetration Testing (VAPT), and there are also Software Composition Analysis tools. Various audit aspects, such as automated and manual audits, play a role. We use both open source and commercial tools to examine source code, provided the customer is willing to share it. We aim to identify vulnerabilities, licensing risks, copyright issues, and operational risks, including deprecated libraries or outdated versions. The findings are consolidated into reports, such as a Software Bill of Material or dashboards, including Power BI dashboards. This approach delivers value to clients, providing insights tailored to different levels of stakeholders, from project managers to executives.
Q. What is a “Software Bill of Materials” and how is it important?
M: More than a technical problem, open source management, is a business problem, revolving around the potential exploitation of software, leading to legal action, customer compensation, and compliance issues, which often result in expenditures on legal advice. Conventionally this problem is handed over to the software development team, composed of technical individuals rather than business experts, and their reflex is to procure tools for resolution. They employ both open source and commercial tools to scan code, aiming to identify vulnerabilities. However, challenges arise as these technical teams grapple with licensing obligations, tool configurations, and the interpretation of the vast data generated by the scanning process. To bridge this gap, we assist companies in defining risk parameters, acceptable policies, and security thresholds, which are then automated into the software development tools. This way, the developers are immediately alerted to security vulnerabilities or unwanted licences as they compile and build code, allowing for timely intervention. The goal is to shift from reactive auditing to continuous compliance and security throughout the development process. In essence, we enable companies to maintain transparency regarding the composition of their software through reports, akin to a food packaging label listing ingredients. This report is the Software Bill of Materials (SBOM) that provides customers with a comprehensive view of the software’s components, enabling continuous monitoring and compliance alerting which ensures that potential vulnerabilities are addressed well before software is shipped. The aim is to establish a professionally managed open source tool, where code undergoes thorough compliance and security testing. This methodology, referred to as “secure by design,” emphasises proactive security measures from the project’s inception.
Q. What are the rules and regulations that accompany the support and encourage the need for compliance in open source?
P: In the United States, laws have been enacted to address security issues related to open source, emphasising the need for control, particularly in vulnerability management. Notably, an executive order issued by the White House in 2021, aimed at improving the nation’s cybersecurity, mandated that any software delivered to a government organisation, whether as delivered software or software as a service, must be accompanied by an accurate software bill of materials. This has legal implications for software companies, especially those exporting to the US, as non-disclosure of vulnerable code could lead to legal liability. Similar initiatives are emerging globally, such as the European Union’s draft Cyber Resilience Act, requiring a software bill of materials for any software delivered to government institutions. Corporate procurement practices are also shifting, with companies starting to adopt the practice of requiring a software bill of materials from their software suppliers. This trend emphasises transparency and ensures that end-user organisations know exactly what is in the software they are using.
Q. How do these regulations affect Indian companies exporting software, and are there associated commercial risks for them?
M: The effect of these regulations on software companies, particularly on the commercial side, is reaching a critical juncture. Software companies may face challenges in selling their solutions to a significant portion of the market if they cannot provide a software bill of materials. While the impact is just beginning, evidence suggests that sales teams, aiming to expand business in regions like Europe and the US, are encountering requirements for a software bill of materials as part of the application or request for proposal process. This requirement compels sales teams to communicate this need back to their development teams, initiating the process of adapting to these new compliance standards.
Q. What are the challenges that your company faces when dealing with Indian clients?
P: In India, there is currently a lack of awareness around compliance, particularly in the realm of open source. Many companies, not only in India but globally, are primarily focused on development. This lack of awareness extends to laws and acts governing compliance, similar to situations observed in the US and European markets. However, it’s anticipated that in the upcoming years, there will be an emergence of regulations and laws, either enacted by the government or other entities, fostering awareness and understanding of compliance impacts. Open source compliance, with its multifaceted nature, involves implementing basic policies and conducting code scans. Our services encompass code scanning to unveil potential vulnerabilities that organisations might not be aware of, even in code that hasn’t been reviewed for several years. In the Indian market, our efforts are directed towards building awareness, engaging with clients through events and conferences, and facilitating a deeper understanding of compliance issues in code, along with providing solutions.
Q. With respect to India, are global players the main customer base or do you see MSMEs also forming a significant portion of your client?
P: The global market is open for business, experiencing a significant increase in compliance requirements. Our focus is on MSMEs because many companies recognize the necessity of compliance, not only due to Indian regulations but also as they export products globally. We aim to assist them in enhancing their open-source domain and compliance. As awareness grows, businesses may see compliance as a crucial aspect either due to its business requirement or to avoid conflicts and litigation. We hope companies prioritise compliance as a means to foster business growth.
M: In India, the government aims to leverage open source, following the principle of “public code, public money.” To avoid vendor lock-in with major companies like Microsoft and Oracle, there’s a push toward adopting more open-source solutions. Our efforts are directed at uniting various stakeholders to establish an open-source program office for the Indian government.
Licensing – a mercurial sport?
Q. How do you advise your prospective clients on what licence to take for what software?
M and P: We initiate a workshop with various stakeholders, ranging from the development team to sales, management, and legal counsel, to comprehend their business model. For instance, if they’re developing cloud solutions and consider the software delivered as a service to be their intellectual property and revenue source, safeguarding it from competitors becomes crucial. During the workshop, we explore the business model and the software delivery method and focus on three critical aspects: knowing what is being used, understanding how it is utilised, and comprehending the associated obligations. Clients often attempt to independently grasp what they are using, but expertise is required for understanding how it is integrated. We create a guide or policy outlining the licences that pose no risk in any scenario, aligning with how they deliver their software solution. Conversely, a set of licences is identified as high risk, with stringent restrictions to protect commercial value. In the middle lies a grey area where the risk depends on software configuration. We synthesise this information and provide recommendations to clients, offering insights on actions to take in specific situations.
Q. Many companies in the open source domain are using AI to develop their code and change it. So in that scenario, how do licensing rules change?
M: AI poses new challenges, particularly in copyright and security. Generative AI systems learn by scanning sources like GitHub for code snippets. When a developer seeks help from a generative AI tool, it searches GitHub for relevant code. However, the legal nuances, such as copyright and licensing information, from GitHub don’t get integrated into the AI tool. Legal cases are emerging where action is taken against AI tools, leading to potential risks for the developers who use the generated code. Another concern is the exploitation of AI by hackers who manipulate the learning process to include malware in code snippets. Developers unknowingly introduce malware, and when the software reaches customers, hackers exploit it. Companies are now questioning the potential risks of developers using AI for coding, even though legal testing hasn’t occurred yet. Open source licensing may need to evolve to address these challenges, but the adaptation hasn’t caught up as of now.
Q. Have you encountered any such situation and how did you deal with that?
M: We had a customer express concerns that their developers might be using AI for coding. Using certain tools, we can analyse code snippets and trace their origin to specific packages, identifying copyright holders and licences. When we investigated, we found some evidence.. Depending on the licences and potential risks, especially for larger projects incorporating AI-generated code, we advised the customer to consider whether they found it acceptable. Interestingly, some companies are opting to halt their developers’ use of AI, given the current uncertainties surrounding this practice.
Q. So when it comes to licensing, are there any licences that specifically govern or regulate the usage of AI?
M: Not at the moment, but I do believe open-source licensing will catch up to that. As the risks get highlighted and brought to the forefront, people react to the risk by modifying the licences.
Q: What is your perspective on transition from traditional open source licensing to source-available licences?
M&P: Initially, open source began as a movement driven by developers who advocated for transparent code accessibility, but companies are now capitalising on source code access, turning it into a revenue-generating strategy. The rise of public clouds like AWS and Azure has played a significant role in this shift. Many companies, offering operating systems such as Linux and Windows, provide them as services in the cloud. We anticipate new developments in licences, particularly with the rise of AI. The emergence of source-available licences addressed the needs of developer-centric communities feeling overlooked for funding and recognition. Established players like AWS and Azure benefitted from open-source products created by companies like MongoDB, RedisLab, and Elastic. The source-available licence aimed to safeguard the benefits of these companies, but it doesn’t align with the open-source initiative’s definition. It deviates from the tenets of both the open-source initiative and the free-software foundation, violating some of their principles. This distinction is crucial for our clients to comprehend.
MongoDB, for instance, initially had a free open source version with a simple Apache licence, allowing developers to use it risk-free. However, with the dominance of AWS and Azure, MongoDB faced revenue challenges as users didn’t need to purchase commercial licences. To counter this, MongoDB introduced a new licence called the Server Side Public License. This licence mandates that if the software is run as a service, the entire solution stack’s source code must be shared—not just the developed portions, which can be impractical for certain components like proprietary backup security. This compelled companies to opt for commercial licences for products like Elasticsearch. Despite providing access to the source code, these licences are now labelled as “source available,” as they impose significant restrictions on its use, limiting the freedoms traditionally associated with open source.
Q. How relevant are open source compliance issues for embedded design companies incorporating RISC-V ISA?
P&M: Open source issues are highly relevant for embedded systems. Embedded devices, such as those in medical equipment like pacemakers, often utilise embedded Linux, customised to meet specific needs. For instance, pacemakers have been subject to hacking, leading the FDA to impose security requirements. A noteworthy case involves Vizio, a TV manufacturer, whose end-of-life TVs continued working due to embedded Linux modifications. The Software Freedom Conservancy initiated a legal case, asserting the right to repair with access to source code. Another example involves Tesla, pressured to share source code for its navigation system after years of resistance, highlighting the challenges in navigating the intersection of embedded open source and proprietary concerns. When embedding code into electronic devices and distributing them, it can trigger licence violations, especially with copyleft licenses. Copyleft licenses stipulate that when providing a product containing certain code to someone else, there’s an obligation to share the complete source code. In embedded systems, this obligation can be easily violated. Therefore, it is crucial to establish checks or gates to ensure companies comply with these obligations. Even if specific checks are not mandated by laws or regulations, companies may still find themselves in violation of certain rules. Understanding the importance of compliance is essential, as failure to adhere to these regulations can lead to legal trouble in the future.
Q. Will open source compliance and regulations change for them as compared to software companies?
M: Managing the same problem in embedded systems follows the same principles we discussed earlier. While the tools for mitigation may differ due to varied code types, all tools are effective for embedded software. The core principles remain consistent: implementing a policy, identifying third-party components, and addressing issues early on. The challenge intensifies if not tackled promptly, especially for embedded devices deployed in remote locations globally. Swift resolution becomes crucial as fixing problems in devices already in operation poses significant difficulties. Therefore, dedicating ample time to address these challenges is imperative.
Q. So do you see embedded designers in India as potential clients and will you have to tweak your services or alter your services for them?
M: Yes, they are potential customers for us. We would adjust the technology used and enhance checks and balances before shipping. It’s crucial to determine whether the embedded systems are receiving code from a third party or building it themselves. If they rely on a third party, our potential clients would be that company providing the code. If the embedded company writes the code itself, there are also potential clients.
A dedicated Open Source workspace
Q. What is the need for setting up an Open Source Program Office (OSPO)?
M: The Open Source Program Office (OSPO) has gained prominence in the past few months. Several major companies, including Amazon and prominent car manufacturers, have established OSPOs. These offices serve as a crucial interface between developers, commercial teams, and legal entities, each with distinct priorities and communication styles. Developers focus on coding, salespeople prioritise selling, and legal professionals aim to impose restrictions. OSPOs act as a bridge, providing tools, knowledge, and guidance to address these diverse concerns. They interpret legal requirements, create tools, documentation, and educational resources, and manage processes. This allows developers to concentrate on their creative work without dealing with compliance issues directly. OSPOs facilitate communication between legal and commercial teams, ensuring that all aspects align to meet customer demands and business objectives.
Q. How do you help a company set up an OSPO?
M: Many companies, especially mid-sized tech companies, lack the knowledge, time, and resources to establish Open Source Program Offices (OSPOs). While large companies may have the resources, they still need the knowledge. To address this gap, we’ve developed training programs covering various licence aspects, management strategies, and examples of pitfalls. The goal is to ensure a common understanding and language across the organisation. Following training, companies often need guides and policies, forming the foundation of their OSPO. Identifying someone within the business to take on the OSPO role, even part-time, becomes crucial. This individual serves as the point of contact for escalations and questions. We provide support to empower them to fulfil these responsibilities. For companies without suitable candidates, we offer an OSPO-as-a-service model, assisting them in establishing and running their OSPO until they can manage it independently.
P: Starting with a small OSPO is advisable, typically within a single department. By integrating previously siloed teams, we facilitate smoother interactions. Our approach emphasises initiating the process on a small scale, observing the positive impact on communication and awareness within the teams. Once teams comprehend the benefits of having an OSPO and how it enhances productivity, we gradually expand the initiative. Through training programs, employees gain the necessary understanding. This incremental process, when executed steadily, can significantly impact the entire organisation.
Q. How should an OSPO deal with the security issues?
M: The OSPO should involve someone from the security team or, at the very least, establish a strong interface with the security team. In some companies, we observed a disconnect where a mature OSPO exclusively focused on licensing, utilising tools to identify components, libraries, and version numbers, showing no interest in security. Simultaneously, the security team independently conducted similar activities. This led to redundant efforts. Therefore, it’s essential to integrate the security team either through communication or representation within the OSPO.
Q. When dealing with clients and who are using multiple open source components, what are your recommendations with respect to securing their supply chains?
M: In a document by CISA, a US-based cybersecurity organisation, it’s emphasised that we don’t need more security products; rather, we need secure products. There are three ways to approach supply-chain security, if starting from scratch. Firstly, if software has already shipped, review it to find vulnerabilities. This is reactive, requiring updates to all existing software. Secondly, before shipping, scan the code for issues and hold back if problems are found. While slightly better, it’s still reactive and can delay the next release. The third, and best, way is at the beginning of the development process, integrating security into the design and deep architecture of the software. Define how to manage security for libraries and packages during the design process. Throughout engineering and development, adopt a secure-by-design approach to avoid security issues initially. This method is cost-efficient, as fixing issues becomes more expensive further down the release cycle. Shifting left, or moving management back to the development phase, helps prevent issues rather than just addressing them later. Recently, a specification known as SLSA (Supply-chain Levels for Software Artifacts) has been launched that addresses various points in the supply chain, identifying eight potential impact areas. It outlines three levels to implement authenticity for these software artefacts, enhancing the overall integrity of the software. Certain specifications, tools, and expertise from firms like source code control can significantly contribute to understanding and securing the entire supply chain.
Q. What are the tools and services that you provide to prevent potential cybersecurity threats?
M: We have a set of tools for software composition analysis that scans the code to identify vulnerabilities. We utilise various tools based on a customer’s software type, development languages, etc. The open-source community offers solutions, like the open-source project “Open Source Review Toolkit.” Major companies like Bosch, Here Maps, Siemens, and engineering and automotive giants also use this tool. It’s a suite of tools scanning and cataloguing code, referencing vulnerabilities, and being open source on GitHub. Our Open Source Review Team provides training and implementation services, helping companies adopt this project for effective supply chain management. The project encourages collaboration and improving the tool for the benefit of organizations.
Q. Doesn’t securing the supply chain right at the design process hinder innovation in any sense?
M: Doing it right does make a difference. Many vulnerabilities in code serve as a developer’s guide to overcoming technical challenges. When developers, focused on resolving specific challenges, search code sites, they may inadvertently introduce outdated or vulnerable code. As this code progresses through the development process, checking version numbers can prevent issues. Tools play a crucial role in this process, instantly alerting developers if the wrong code version is pulled in. Open Source’s strength lies in the community’s ability to fix issues quickly. However, without the updated version, vulnerabilities persist. Notably, tools with browser plugins offer real-time guidance as developers browse code, aiding in avoiding potential pitfalls. This automation, akin to AI, provides developers with efficient tools that seamlessly integrate into the development cycle.
Q. How can developers embrace innovation in open source while ensuring regulatory and legal compliance?
M&P: Open-source projects thrive on contributions, fostering collaboration and attracting developers eager to participate. This collaboration extends beyond workplace hours, with developers dedicating time to open-source projects. Many corporations permit developers to contribute on behalf of the organisation, benefiting both developers and the companies they work for. This practice, exemplified by Linux, has contributed to its immense success. Businesses that restrict developers from contributing often struggle to attract and retain talent. But, developers might view compliance as a hindrance, as their primary focus is on swift development and bringing products to production. Compliance introduces a necessary pause to evaluate the safety of what they’re building for users and customers. Building awareness among employees, especially developers, is crucial to help them understand the significance of open-source compliance. Recent incidents like the Log4j vulnerability and breaches at Equifax underscore the importance of addressing security vulnerabilities in open-source software promptly.
