It is encouraging to see a thriving community within the cybersecurity industry clamoring to share experiences as conference season approaches. As a result of the call-for-speakers process, attendees can get a pretty clear idea of what's on the minds of the entire ecosystem of cybersecurity professionals across the globe. 

This year's "RSAC 2023 Call for Submissions Trends Report" examined several noteworthy trends related to open source, one of which was open source's ubiquity and decreasing resemblance to silos, a trend that has been observed in previous research about the RSAC 2023 call for submissions. There are both benefits and risks associated with the changes in modern software. 

There is no doubt that cybersecurity professionals spend much of their time discussing software and how it's assembled, tested, deployed, and patched to protect against malicious attacks. 

A company's software has a profound effect on its success, regardless of its size or sector. As scale and complexity have increased over time, teams and practices have evolved to meet these challenges. In light of this, Jennifer Czaplewski, senior director at Target, where she leads DevSecOps and endpoint security, says this has led to more assembly than the writing of software in the modern day. She is also a member of the program committee for the RSA Conference. This is not just a matter of opinion, it is a fact. According to estimates made by industry experts, 70% to almost 100% of all software across the industry contains open-source components. These are codes that can be directly attacked in small and large attacks. It creates a huge, shifting attack surface that everyone should be keeping an eye on, as well as an area of focus for everyone to work on. 

While you are designing and assembling code, you are bound to discover a lot of dependencies that you will have to deal with - both transitive and widespread. A team integrating the code will also need to better understand the process used to run, test and maintain it. This will enable them to bring these dependencies to the table more effectively. These dependencies extend much deeper than the actual code itself. 

Even though cybersecurity professionals spend a lot of time talking about software, it comes as no surprise that they spend a lot of time discussing how it is assembled, tested, deployed, and patched. Each business, regardless of its size or sector, has been impacted by software to some extent or another. The growth of scale and complexity has led to the evolution of teams and practices as well. Therefore, DevSecOps and endpoint security are constantly being integrated as a result, and Jennifer Czaplewski, a senior director at Target and a member of the program committee for the RSA Conference, says "Modern software is being assembled more than it is being written." This is not an opinion but a fact. As much as 70% to nearly 100% of all software across the industry contains open source components - code that is targeted directly in attacks of all sizes - estimates suggest this is a huge, shifting attack surface that requires all companies' supply chains to be vigilant. This creates an area of focus for every industry.

Code assembly creates a wide range of dependencies that are natural artifacts that arise as a result of the assembly process. The team that is incorporating it also needs to understand the processes used to run, test, and maintain the code. This is because they are deeper than the actual code. 

There is no escaping today's reality - almost every organization today relies unavoidably on open-source software to run its operations, which has led to an increase in the demand for better methods of assessing risks, cataloging usage, tracking impacts, and making informed decisions about the integration of open source components into software stacks before, during, and after they have been integrated. 

As a technology issue, open source isn't the only issue that concerns open source. Alternatively, there may be a problem with the process. There could also be an issue with the people involved. As you might expect, it touches everything, including top-level executives, heads of information security departments (CISDs), policymakers, and developers. It is vital to establish trust across each of these groups by building transparency, collaboration, and communication between them. It is apparent that the software bill of materials (SBOM) has become one of the primary elements for building trust and has become popular after the May 2021 executive order from President Biden. 

In recent years, people have been able to observe tangible and quantifiable results as a result of the implementation of this solution. These results include how well assets are managed, how quickly vulnerabilities are addressed, and how strongly software life cycle management is improved. DBOM (data) and HBOM (hardware) seem to have gained traction, which has led to the creation of additional BOMs, such as PBOM (pipeline) and CBOM (cybersecurity), with SBOM generating additional BOMs. Many are hopeful that the BOM movement will be able to lead to a uniform and systematic way to think about and approach problem-solving in the future, but only time will tell whether the benefits outweigh the heavy responsibility placed on developers. 

Several policies and collaborations have been put into place to encourage the practices that have led to the success of open-source software, including the Securing Open Source Software Act, the Supply Chain Levels for Software Artifacts (SLSA) framework, as well as the NIST Secure Software Development Framework (SSDF). A common goal, namely to ensure that software supply chains are secure by default, has enabled the entire community to work together. 

There is an overt focus on the downside of open-source code, including potential manipulation, attacks, and exploitation of it. This is leading to increased efforts to mitigate associated risks, both through the development process, analytical reports, and even technology, to mitigate those risks. There is a great deal of effort being put into preventing malicious components from being ingested into the body in the first place. 

As a result of this introspection and personal learning around software development, the software development life cycle (SDLC), and the supply chain generally, there have been a lot of benefits to the community at this moment in time. Indeed, open source can greatly impact the success of ... open source! The continuous integration/continuous delivery pipeline (CI/CD) that developers are accustomed to using relies heavily on open-source tools to integrate critical security controls during development. OpenSSF scorecards and the OpenSSF Secure Supply Chain Framework are both examples of promising initiatives that will help teams in assembling software by providing resources such as automated scoring and consumption-focused frameworks that protect developers against real-world threats related to OSS supply chains. Just two examples of promising activities that will assist teams in assembling software include the Secure Supply Chain (SSC) Framework. 

Even though open-source software continues to change the game of software, it has already changed it. There has been an impact on the way software is developed all over the world due to it. In addition, it has expedited product development time. A reduction in development costs and stimulation of innovation have been two of the benefits. 

While it can be argued that the updated system has contributed to security in the long run, work needs to be done. To make the world safer, we must work together as a village by sharing ideas and best practices throughout our communities. This will enable us to build a more secure world.