View all on-demand sessions from the Intelligent Security Summit here.
Chief Information Officers (CIOs) see security as the biggest challenge for IT organizations. And 82% of them say their own software supply chains are vulnerable.
As security threats continue to evolve and become more sophisticated, developers have been drawn to work closely with security teams to build a layer of security from the ground up and ensure measures are taken throughout the development lifecycle.
As a result of these and other factors, cybersecurity has become an increasingly costly issue. In a recent report, McKinsey predicted that the damage from cyber attacks will amount to approx $10.5 trillion annually by 2025, a 300% increase over 2015.
At the same time, governments around the world have learned of the risks to the software supply chain. In the US, the Cybersecurity and Infrastructure Security Agency (CISA) has released a list of cyber performance goals designed to protect critical infrastructure across the country. For now, these guidelines are voluntary, but there are signs that they could serve as a basis for federal regulation.
This is a positive sign, but as it stands, there is one group that is increasingly stepping up the defense lines in the battle for data security: developers.
Four pillars for securing the software supply chain
Security teams are tasked with doing whatever it takes to secure their organization’s data, but with the increasing number and methods of attacks on the software supply chain, it becomes a tough question. Enforcing policies across a wide range of activities is a growing concern, and security teams are also tasked with implementing compliance and best practices.
The result in many organizations is overstretched teams and a “downstream” effect on development teams that are inevitably called in to solve and strengthen the myriad of often underappreciated supply chain problems.
The harsh reality is that most organizations don’t have an engineer or leader whose sole focus is on DevSecOps. In this case, it is becoming increasingly common for security and development teams to collaborate from the very beginning and build security into their applications and operations.
With developers playing a more important role in the data security battle, there are four pillars to consider when it comes to securing the software supply chain:
More attention to software packages
At the most basic level, software packages are modules of code put together to form an application. A common strategy among malicious actors today is to attack compromised packages that contain more than just the source code. There may be sensitive keys, configurations or other components that can make an organization vulnerable.
As a line of defense, developers need both the tools and the knowledge to uncover problems in packages that aren’t just visible in the source code, to gain a full understanding of the impact of potential exploits.
Understanding the context in which software works
In addition to software packages, developers need to know and understand the context in which software operates in order to best protect it. Specifically, they must identify and recognize misuse of OSS libraries, insecure use of services, disclosed secrets, and infrastructure-as-code (IaC) configuration issues. They then need to identify the applicability and exploitability of the most serious vulnerabilities in their applications.
Common vulnerabilities and exposures (CVEs) may or may not be exploitable depending on an application’s configurations, authentication mechanisms used, and key disclosure. Developers, working with security teams, must verify whether the libraries, services, daemons, and IaC they rely on are being exploited or misconfigured across a software supply chain, including on-premises, in the cloud, and at the edge.
Ensuring that every process and tool is security-enabled
Ideally, developer teams should manage all artifacts and repositories in one place, creating a single source of truth for an organization. When development teams have control over their entire portfolio, security is a natural and smooth process from the start – the single source of truth becomes a single source of trust.
When properly managed, every DevOps process and tool requires and includes security. The idea is to unify, accelerate and secure the delivery of software from developer to deployment. Security teams define strategies and policies, while development teams restore and manage codebases. Packages, infrastructure, integrations, releases, and flows all need to be addressed to enable a workflow that works for core DevOps teams, not just security and developer groups.
Discover vulnerabilities before they are exploited
Most organizations should work with outside analysts or open source communities with advanced research experience to discover vulnerabilities before they are exploited. This gives companies the ability to quickly respond to new attacks as they become more prevalent in the industry, enabling them to quickly update databases with contextual analysis that mimics the researchers’ work.
Enabling innovation
By implementing security throughout the development process, developers can, well, develop. By applying the above strategies, they don’t spend all day fixing security issues they don’t understand, while they get easier and faster ways to fix vulnerabilities and know they’re resolving them completely.
There is no question that security is a real and vital concern, but winning organizations are the ones that make it a priority throughout the entire software supply chain. This allows their developers to innovate and move the business forward.
Nati Davidi is SVP of Security at JFrog.
Data decision makers
Welcome to the VentureBeat community!
DataDecisionMakers is where experts, including the technical people who do data work, can share data-related insights and innovation.
To read about advanced ideas and up-to-date information, best practices and the future of data and data technology, join DataDecisionMakers.
You might even consider contributing an article yourself!
Read more from DataDecisionMakers