Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Home working is ripping the heart out of cities, the DoD’s bizarre cloud strategy, and Apple adds a $10,000 app price option. (more…)
Chainguard today added a private preview of a Chainguard Enforce Signing service, enabled by the open source Sigstore project, that allows developers to generate digital signatures for software artifacts using identities and one-time-use keys they create themselves.
Kim Lewandowski, head of product for Chainguard, said Chainguard Enforce Signing provides an alternative to relying on a public service to generate those digital signatures. It also allows organizations to bring their own key and certificate so that key usage can be monitored and audited per compliance and privacy requirements.
In addition, Chainguard added a library of policies that administrators can deploy directly from the Chainguard Enforce web console to their environments.
The Chainguard Enforce Signing feature is based on Sigstore, an open source project that provides a protocol to simplify cryptographic certificate generation by removing the need to manage keys. At its core, Sigstore creates a set of short-lived ephemeral keys with a trust root based on an auditable public log. Because it creates an immutable log, everyone participating in the software development process, including auditors, can now transparently track the chain of custody for any software artifact.
Key management, key compromise/revocation and the distribution of public keys and artifact digests are challenging to manage. Developers are also required to determine which keys to trust in addition to learning how to sign them when different platforms are employed.
Chainguard’s alternative is enabling organizations to host their own immutable log rather than relying on a public service to eliminate the need to manage keys, noted Lewandowski.
Historically, code signing platforms have been problematic because they were susceptible to tampering. Cybercriminals can, for example, swap out digests to gain access to compromised credentials. Digests and public keys are also often distributed across vulnerable websites susceptible to hacks or inadvertently stored on a public Git repository.
Code signing—along with software bills of materials (SBOMs)—is one of two technological advances that will improve the security of software supply chains. SBOMs, of course, are going to be considered more reliable when the software components they describe are signed by the developers that created them.
Less clear is whether the signing of code will improve its overall quality. Most developers take pride in their code, but the overall quality of the software deployed in production environments could always be improved. Developers may decide to review the code they contribute to a build more intently if they know they will be required to sign it.
In the meantime, it’s only a matter of time before organizations require that developers sign code before it is deployed in a production environment. In addition to increasing confidence in the quality of the code employed, those signatures make it simpler to track down the development team that created code whenever there is an issue that needs to be resolved. After all, the most challenging issue organizations encounter when trying to update software is not so much the creation of a patch as much as it is identifying who should create that patch based on their knowledge of the software components used.
Modern applications are dynamic. They’re distributed and they’re often born in the cloud. These applications can be developed on the fly, spun up and scaled quickly to meet evolving user and market demands—enabling a level of business agility that allows users to make quick, informed decisions in real-time and take advantage of opportunities as they arise.
Enabling this development velocity are tens of thousands of open source libraries–pieces of code that developers can include in their applications to perform a specific function without having to code it from scratch. Open source libraries prevent developers from having to reinvent the wheel and allow them to focus on their differentiated business logic. While efficient and a major time saver, open source software may be the biggest single threat to software supply chains today. Developers simply have too much faith in the integrity of free, open source code that they casually include and distribute with their applications.
Despite the operational benefits, the pressure to develop quickly shouldn’t expose the organization to increased security risks. Development teams need to rethink how they use open source software and take steps to ensure they meet the same security standards as other enterprise applications.
The problem is that most open source projects are maintained by a small number of developers that contribute their time and expertise to build software components that can be reused by the community at large. However, these developers are volunteers who aren’t being paid for their time and effort, nor are they under the same pressure as enterprise developers to ensure there are no vulnerabilities in their code. They may also lack the level of enterprise security expertise necessary to protect applications from increasingly sophisticated attacks. Some may even be hostile to efforts to better secure their code if it means slowing performance or changing the user experience.
The result is that insecure code is increasingly making its way into enterprise applications that use these open source libraries. In fact, the Log4j vulnerability last year was due to a vulnerability in an open source Java logging library. Recognizing the national security importance of open source software, the Biden administration recently issued an executive order and met with cybersecurity professionals to better safeguard the federal government’s computer systems. The resulting recommendations included policies that would help prevent security vulnerabilities in open source packages, improve the process for identifying and fixing defects and reduce time to remediation for distributing and implementing fixes.
It’s imperative that the private sector take notice and make more of an industry-wide effort to secure open source software that makes up businesses’ most critical applications today.
The bottom line is that enterprises themselves need to take more responsibility for securing enterprise applications—especially as these applications rely more on open source libraries. They need to take a more proactive approach that spans the entire software life cycle, embeds security tools directly into development platforms and provides complete transparency into what makes up their most critical applications.
Here are three things organizations can do to make sure their open source software is secure:
1. Continuously conduct end-to-end application testing
Modern applications are constantly evolving—making it more imperative than ever to continually test for vulnerabilities throughout the entire software life cycle. Starting with the planning stage, security should be embedded throughout the process—providing developers with a solid framework for building secure code before it goes through testing. Once pushed, application security testing should continue as an automatic, built-in step when pushing code to production. DevOps and security teams should work together to ensure security is no longer an afterthought to feature development.
2. Embed enterprise security capabilities directly in development platforms
Forcing developers to take an extra step to ensure secure code when they’re already under pressure to push code quickly is a recipe for failure. Security teams must make it as easy as possible by integrating security controls directly into existing development processes. Standardizing security testing and controls during development makes it more likely policies are recognized, understood and followed.
3. Ensure transparency in every snippet of code you use
Complexity is the enemy of good application security. DevOps teams need to know exactly what makes up their applications—including open source libraries and their dependencies. The federal government is pushing the open source community to standardize a software bill of materials (SBOM). Similar to regulations that require hardware manufacturers to know where every part is sourced, this would force both open source developers and enterprise developers to take more responsibility for the code they include from other sources. That way, if a vulnerability is discovered in a library, enterprises could easily determine if they are at risk and take appropriate action to fully mitigate the issue as quickly as possible.
Open source software enables the kind of development agility that makes businesses thrive, but open source also greatly expands enterprise threat surfaces—leaving many organizations at risk of a breach. Organizations need to take greater responsibility for the security posture of the open source libraries they use to speed application development. This requires end-to-end application testing throughout the entire software development life cycle; embedded security tools and controls in development platforms and processes and complete transparency into the open source software that makes up critical enterprise applications. This proactive approach will ensure that vulnerabilities such as Log4j are identified and patched quickly before threat actors are able to exploit them and compromise applications.
A report published this week by Synopsys in collaboration with the Consortium for Information & Software Quality (CISQ) estimated that software quality issues might adversely impact the U.S. economy to the tune of $2.41 trillion in 2022.
Cybercrime losses due to a rising number of software vulnerabilities alone are on track to increase 42% in 2022 after growing 64% in 2021, according to the report.
More troubling still, the number of failures due to weaknesses in open source software components accelerated by an alarming 650% from 2020 to 2021.
Finally, the report estimated that overall technical debt would increase to $1.52 trillion in 2022.
Dr. Anita D’Amico, vice president of cross-portfolio solutions and strategy for Synopsys Software Integrity Group, said that despite these issues, there is cause for optimism. The silver lining is that more organizations are aware of software supply chain issues in the wake of a series of high-profile breaches.
As more responsibility for application security also is shifted further left toward developers, the number of vulnerabilities being introduced into applications should also begin to decline steadily, she added. In addition, more organizations will soon be following the lead of the federal government by requiring software bills of materials (SBOMs) that will make it simpler to remediate vulnerabilities once they are discovered, noted D’Amico.
Of course, there are still many cultural and technical issues that need to be resolved before DevSecOps best practices are consistently employed across most organizations. However, the expectation is that cybersecurity teams will be able to concentrate more on crafting cybersecurity policies as application development and IT operations teams assume more responsibility for implementing those policies, said D’Amico.
But while giving individual developers the tools they need to write more secure code is a major step in the right direction, there is also a need to make sure the builds to which they contribute code also remain secure. As such, DevOps teams need to implement guardrails across every stage of a DevOps workflow to make sure vulnerabilities are not created as code is merged. In addition, DevOps teams now need to be aware of any malware added to an open source software component downloaded from a compromised repository. Even once patched, there’s a good chance another developer will have downloaded the same vulnerable component to construct a different application.
No one knows for certain how many vulnerabilities may have already been introduced into production environments, but it’s unlikely all those issues will ever be completely addressed. Organizations with limited technical resources will need to prioritize the patching of the most severe vulnerabilities in their application environment based on how accessible code may be to cybercriminals.
Cybercriminals certainly are getting more adept at exploiting vulnerable code. Developers may soon find themselves being required to update software components deployed by someone else many years earlier. In the meantime, more accountability for application security should lead to better quality code that, over time, will reduce the current unsustainable level of technical debt.
A global survey of 606 IT, security, application development and DevOps decision-makers found that the biggest barrier to adoption of DevSecOps best practices is cultural rather than technical. However, the survey, which polled organizations with more than 500 employees and was conducted by Progress, also found only 16% of respondents planned to prioritize addressing those cultural issues in the next 12 to 18 months.
A full 71% of respondents cited culture as the biggest barrier to DevSecOps progress, with only 30% expressing confidence in the current level of collaboration between security and application development teams currently being achieved. In contrast, 46% of respondents were not particularly confident while nearly a quarter (24%) were not at all confident.
Nevertheless, well over half of respondents (57%) said security threats are the number-one technology factor driving the evolution of DevSecOps, even though just over half (51%) admitted they were only somewhat familiar with how security fit into a DevSecOps workflow.
Overall, 86%of respondents said they are experiencing security challenges that include prioritizing externally facing applications over internal applications (47%), securing different types of workloads that were using different development and delivery methodologies (46%), meeting delivery deadlines (45%) and meeting audit requirements specified by the security team (39%). Just over three quarters (76%) recognized they could be more strategic in managing DevSecOps.
The top three initiatives needed to support a shift to a more strategic DevSecOps approach identified are more investment in continuous learning for developers and engineers (61%), upskilling of developers and engineers to move into site reliability engineering (SRE) roles (60%) and improved communication between developers, security and operations (60%).
Survey respondents also identified a need to define a clear set of policies and procedures (66%), define the role and responsibilities of staff across teams (62%), create a continuous feedback loop (49%) and automate recurring security tasks (41%).
Despite that level of awareness, however, only 40% said they believed implementing security training and upskilling efforts across multiple stakeholders was very important when implementing DevSecOps.
Prashanth Nanjundappa, vice president of product management for Progress, said given all the cultural and technical challenges organizations face, it’s apparent that both a top-down and bottom-up approach to implementing DevSecOps best practices is required. Attempting to shift responsibility left toward application development teams is not going to suffice on its own, he noted.
The survey also suggested that many organizations are trying to address application security issues as they modernize their application portfolio. A total of 59% said they struggled to attain buy-in/funding for refactoring efforts that didn’t provide new user capabilities. However, only 39% said they had adopted a comprehensive modernization approach based on cloud-native architecture principles, while another 22% felt they lacked one entirely. Just under a quarter (24%) said their approach to modernization is to largely rip-and-replace applications.
The top business factor driving the adoption of DevSecOps was a focus on business agility enabled by fast and frequent delivery of application capabilities (59%). Just under half (45%) said it had taken six to 12 months to achieve a return on DevSecOps investments, while 31% said it had taken longer than a year. However, only half (50%) of respondents were familiar and interested in both infrastructure and policy-as-code.
There is no doubt that the DevSecOps journey ahead will be long and arduous. However, there are also a wide range of small process changes that could have a massive impact in terms of improving application security in the short term. The challenge is to quickly identify those opportunities while at the same time employing a more systematic approach that ultimately makes it a lot simpler to implement a set of DevSecOps best practices consistently.
While ransomware has been the leading concern for enterprise security teams over the few past years, software vulnerabilities are nipping at its heels. The boom in cloud-based apps and services and increased digitization of work have been a boon for hackers, who are taking advantage of developers’ and DevOps teams’ attempts to work faster and smarter to keep up with demand. One estimate says that four out of 10 zero-day attacks carried out in the last decade happened in 2021 alone.
Many things account for this increase. Developers are stretched and are reusing code, which allows for misconfigurations and vulnerabilities to reappear unexpectedly in different programs, and the use of multiple cloud services fragments security measures and reduces visibility into the code running many enterprise functions. This is why developers and security professionals alike are paying more attention to security throughout the software development life cycle (SDLC), particularly in the early stages.
The zero-day surge has led to an increased interest in shift left practices as a way to make security a priority in the development process. Shift left culture brings security into the equation much earlier in the software life cycle, before the software is deployed, rather than patch bugs after users report them. This preemptive approach helps head off vulnerabilities that can affect an application’s security posture unbeknown to its defenders.
Shift left principles can also enhance security when developers build applications for cloud platforms—such as Amazon Web Services, Microsoft’s Azure or Google Cloud—where visibility into the proprietary code and security tools of the platform can be limited. In a shift left culture, DevOps embeds least privilege policies as part of the daily work on cloud workloads, to protect network infrastructure and avoid granting excess permissions on those workflows.
For example, setting up role-based access control (RBAC) on Kubernetes containers enforces a least privilege model on those clusters and avoids excessive permissions that can lead to a breach, while removing admin credentials from continuous integration/continuous delivery (CI/CD) workstations shuts off hackers from using those pipelines as an attack vector.
Shift left security is a great concept, but runs into hurdles in execution, mainly the internal conflict between development teams who want to move at the speed of business while security staff takes a more cautious approach. This leads to friction, with developers warning about access denials affecting their work and causing deployment delays, while the security analysts worry about data breaches caused by too many users with unchecked admin privileges.
Working out this friction requires a mindset shift, where DevOps understands that security is part of the development process, and management can trust that developers have security in hand. This also requires tools and training to integrate shift left practices, such as platforms that can bridge the security needs of the CISO (by granting greater visibility into the network infrastructure code, for example) and the agility needs of the DevOps teams (by automating security guardrails and entitlements, for example). The ultimate goal is creating what is known as a DevSecOps model, bringing together development, security and operations into one agile, safe and efficient workflow.
Four best practices can help:
● Gain deep visibility: With enterprises often working in multiple cloud environments—and mixing public and private clouds into hybrid infrastructures—visibility into assets typically suffers, which makes getting a clear view of risk difficult. Being able to discover all identities, permissions, configurations and resources in the environment and all the access paths to specific resources can help build a contextual inventory of cloud assets to better manage them and carry out policy analysis.
● Prioritize risk: Risk management is a key practice of any security program, but the flood of alerts from multiple cloud providers and systems can overwhelm security operations centers, which are often short on talent and time. Automation tools can now search and prioritize risks across an entire cloud environment, from development to production, spotting problem combinations and alleviating the workload of sorting manually through alerts across multiple silos, freeing the staff to work on higher-priority mitigation and remediation tasks.
● Just-in-time access: Zero-trust architecture has become the standard to aspire for most security defenses, but it is often challenged by the difficulties of managing access privileges. Just-in-Time (JIT) access, granting limited-time revocable rights, is a useful tool for building a zero-trust security architecture and enforcing least privilege policies to maintain it. Technology tools that actively manage and monitor developer access to cloud environments, including a strong audit trail of privileged activity, give security a means to enforce JIT access and zero-trust in turn.
● Find and prevent vulnerabilities and misconfigurations: Infrastructure-as-code (IaC) has made software deployment in the cloud (much more agile and efficient with the use of virtual machines, containers, microservices, etc. However, security is often an afterthought both pre- and post-production when standing up cloud infrastructure. Organizations should scan code for security policy violations and other risks in order to mitigate flaws before they reach production and to detect and fix problems in production environments. With feedback and automated guardrails built into development workflows, DevOps and security teams can reduce security risks in their code.
Like zero-trust, shift left is on its way to becoming a standard practice for cybersecurity assurance. But building a DevSecOps model takes more than good intentions. It requires practices, tools and training to execute that model, and a mindset of partnership across the enterprise and with outside cloud and security partners. Only a group effort will provide the cloud security assurance an agile business needs.
However, all entertainment apps share a few key traits in common:
They typically host dynamic content that is unique for each user. This makes entertainment apps different from apps where most or all of what each user sees is the same.
They host rich multimedia content including, in many cases, streaming audio and video.
They are often created by vendors operating in highly competitive markets, where a poor user experience can send users flocking to competitors’ apps. There is no shortage of apps out there for gaming, video streaming and so on, and if your app fails to perform, your users can easily convert to a competing solution.
For these reasons, teams responsible for testing entertainment apps must develop a testing strategy tailored to the unique challenges of these applications. Traditional testing tools and methodologies aren’t enough for running tests that support an excellent end-user experience for entertainment software.
With that reality in mind, let’s take a look at four best practices to follow when testing entertainment apps. These strategies go a long way toward ensuring that entertainment apps deliver the end-user experience that is necessary for maximizing user engagement and retaining users, no matter how complex or dynamic the apps happen to be.
An easy – and all too common – way to shred the user experience in an entertainment app is to stream videos where the visual and audio streams go out of sync with each other. Videos need to be perfectly in sync with audio to keep users happy.
Of course, the challenge that testers face is that most testing frameworks don’t offer an easy means of evaluating whether visual and audio content are in sync with each other, especially when the content is streamed. Frameworks that let you evaluate when content initially loads or when it updates aren’t enough for analyzing sync between visual and audio streams. As a result, teams have traditionally resorted to testing for sync manually, or not testing it at all.
Fortunately, there’s a better way. Using AI, you can run tests that automatically identify lag between video and audio. In turn, you can detect problems that may cause streams to go out of sync, then fix them before your users experience sync issues.
When you have an entertainment app where content changes in real-time, your tests need to be able to execute and display results in real-time, too. But that’s difficult to do if network latency issues prevent data from moving between your test cloud and your testing tools quickly enough to provide real-time results.
There are two ways to solve this challenge. First, you could run tests on on-premises devices in order to avoid network latency problems. Alternatively, if you want to take advantage of a test cloud while still achieving real-time results, you can optimize network traffic in a way that minimizes latency and allows test data to flow between your test cloud and your testing tools in a few dozen milliseconds–as opposed to the hundreds of milliseconds traditionally required for packets to flow from tools to the device cloud, and then back again.
The way a user based in, say, Barcelona experiences an entertainment app might be quite different from the way one located in New York or Tokyo experiences the same app. The reason why is that the network hops over which data needs to travel, as well as the efficiency of the carrier network that delivers the data, which can have a major impact on how quickly content loads and is streamed. For media-rich entertainment apps, latency and bandwidth limitations can be particularly problematic.
For this reason, you should be testing your entertainment apps from the perspective of users spread across the world. Doing so allows you to represent multiple geographies and carrier networks in your tests, ensuring that your app performs properly not just from the location where your testing team is located, but from all of the locations where your actual users reside.
Variations in screen resolution can have a significant impact on how content is rendered. Attempting to display content at a screen resolution that software developers didn’t plan for can result in pixelated images, distorted images or images that aren’t fully visible.
That’s why you should be testing how content on your entertainment app is rendered under different screen resolutions. Testing for just one or a handful of resolutions isn’t enough.
You can perform these tests manually, by reviewing content rendering by hand. A better approach, however, is to take advantage of AI tools that can automatically compare renderings of the same content under different screen resolutions to detect inconsistencies. That’s a much faster, more efficient, and more scalable way to ensure your content appears as users expect it to.
Entertainment apps are a unique category of software, and they require a unique testing strategy. Testing teams need to test for factors that aren’t important for most other types of apps, such as evaluating whether video and audio streams are in sync. They also need to minimize latency during testing and test across multiple geographic locations and screen resolutions. Practices like these are the only means of ensuring that entertainment apps deliver the user experience necessary to succeed in highly competitive niches.
Rezilion has added support for Windows applications to its tool for dynamically generating software bills of materials (SBOMs).
Rezilion CEO Liran Tancman said in addition to existing support for Linux applications, it’s now possible to analyze all the components that make up a Windows application runtime environment in real-time.
That capability also makes it possible to search for and pinpoint the location of components, such as the Log4j vulnerability, across millions of files and on thousands of hosts, containers and applications, he added.
Rezilion has created a searchable proprietary next-generation vulnerability database (NGVDB) that identifies which issues impact specific classes and functions. In addition to surfacing remediation suggestions, the capability also reduced the number of false positives that IT teams would otherwise have to track down.
The SBOM tool the company provides builds on that capability to provide insights into the complete attack surface of an application that could be exploited by cybercriminals.
In general, the components of a Windows application are more challenging to track and analyze because of the many different frameworks created to build them over the last few decades. However, with more than half of all applications running on Windows, the need to create SBOMs for those applications has become a more pressing concern, especially in the wake of an executive order issued by the Biden administration that requires federal agencies to provide SBOMs for every application they use.
It’s not clear how many enterprise IT organizations will be following suit, but the general expectation is that SBOMs will soon be a lot more prevalent than they have been. In the wake of a series of high-profile cybersecurity breaches, there is now more scrutiny of software supply chains than ever.
The challenge, of course, is determining which vulnerabilities to remediate first once they are identified in an application. There are simply too many vulnerabilities to patch all at once, so DevOps teams need to be able to identify which vulnerabilities are the most severe. For years, cybersecurity teams have been creating spreadsheets filled with long lists of vulnerabilities, but there is usually no context provided in terms of how severe a vulnerability is. As a result, developers would allocate a small portion of their time to applying patches that are prioritized based on intuition and level of complexity rather than severity.
It may still be a while before most organizations that build software are able to consistently create accurate SBOMs. It may be even longer before the organizations that consume those SBOMs have the processes in place to operationalize them. In theory, an organization, if necessary, should be able to prevent software from being deployed based on the list of components included in the SBOM. However, that decision is not always straightforward. There is usually a range of reasons for including a potentially vulnerable component in an application that needs to be considered.
One way or another, the overall security of applications is about to steadily improve. The only issue is how much pain will need to be experienced to achieve that goal.
Organizations are struggling to improve DevSecOps practices as they confront a lack of cultural alignment and investment, according to a global Progress survey of more than 600 IT, security, application development and DevOps decision-makers.
Many companies are behind in achieving their DevOps and DevSecOps goals, with 73% of organizations saying they could be doing more.
More than three-quarters (76%) of respondents acknowledged they need to be more strategic about how they manage DevSecOps, and 17% said they still consider themselves at an exploratory and proof-of-concept stage.
Prashanth Nanjundappa, vice president of product management at Progress, said the most surprising finding was the evident contradiction between what organizations think is very important and their actual alignment, commitment or investment.
“While security is the number-one driver behind most DevOps and DevSecOps implementations, just 30% said they felt confident in the level of collaboration between security and development,” he added.
Meanwhile, 86% of respondents are experiencing challenges in their current approaches to security and 51% admitted that they don’t fully understand how security fits into DevSecOps.
Nanjundappa pointed out that company culture is, in fact, biggest barrier to DevOps and DevSecOps success.
“We found 71% of respondents agreed that culture is the biggest barrier to DevSecOps progress, yet only 16% were prioritizing culture as an area to optimize in the next 12 to 18 months,” he explained.
The study revealed the top business factors driving the adoption and evolution of DevOps inside their organizations included a focus on agility as well as reducing the business risk of quality, security and downtime or performance issues.
Organizations also recognized the need to implement DevOps to support a cloud mandate or their move to the cloud.
In addition, concerns about public cloud workloads, increasing regulatory requirements and concerns about financial impacts are driving how security around DevOps is approached.
“Organizations are juggling lots of priorities in how they manage security with key focus areas for security being digital marketing efforts, employee apps and customer-facing apps,” Nanjundappa said.
Challenges with security include prioritizing the development of external-facing capabilities over internal apps, the ability to secure different workloads using different development and delivery methods, meeting delivery deadlines and difficulties meeting audit requirements.
“Through the survey, we have seen some of the differences that stand out between organizations that have achieved higher maturity versus others,” he noted.
Some are related to cultural aspects and bring to the fore a focus on business agility through fast and frequent delivery of application capabilities, as well as using DevOps to better manage distributed and/or remote work environments.
Nanjundappa said among the best practices to ensure fruitful collaboration are stakeholder sponsorship on leadership for tools and outcomes aligned with the strategic direction of organizational goals.
“Let teams innovate at the grassroots level with regard to tools and processes to accomplish expected outcomes,” he explained. “Identify teams which have seen success, celebrate those successes and implement those processes across other teams in an iterative model.”
As organizations head into 2023 with a tight IT labor market persisting, Nanjundappa pointed out a key concern will be to find the talent they need to make these DevSecOps initiatives a reality.
“While it is ideal to hire pre-trained talent which fits their organizational needs, it will either be expensive or sometimes close to impossible for multiple reasons,” he said.
He recommended using a multi-pronged approach to bridging talent gap, which includes an on-ramp for hiring experienced key talent and reskilling through cross-pollination of experiences from different teams, including security, dev and ops.
Nanjundappa also advised upskilling existing teams with modern technologies, replacing legacy platforms and tech with cloud and cloud-native technologies and augmenting that with the right level of tools and processes, including policy-as-code and CI/CD.
Palo Alto Networks this week extended its efforts to secure application environments by agreeing to acquire Cider Security, a provider of a platform for securing continuous integration/continuous delivery (CI/CD) platforms, for approximately $195 million in cash.
The acquisition of Cider Security, scheduled to close this quarter, will extend the reach of the company’s Prisma Cloud platform that was updated last year to include a set of tools for securing infrastructure-as-code (IaC) used to provision IT infrastructure. Palo Alto Networks previously acquired Bridgecrew, which had developed an open source Checkov policy-as-code tool. Last month, Palo Alto Networks added software composition analysis tools to Prisma Cloud, as well.
Cider Security developed what it described as an operating system for application security. The solution creates a graph that enables DevOps teams to visualize the relationships between all elements that make up a software development environment, including code. It then makes it possible to apply a set of controls to remediate any vulnerabilities and attack paths that might be identified using any number of third-party scanning tools.
Palo Alto Networks CEO Nikesh Arora told industry analysts the acquisition is an example of the company doubling down on securing software supply chains alongside its existing portfolio of platforms and services for securing production environments.
It’s not yet clear who is in charge of DevOps platform security, but increasingly there will be some type of central security function that works with application development teams to lock down software supply chains, said Mike Rothman, general manager for Techstrong Research, an arm of the parent company of devopsy.kinsta.cloud. “There’s going to be a central security group focused on securing the pipeline,” he said.
As Palo Alto Networks continues to extend the reach of Prisma Cloud left, it continues to make a case for centralizing the management of cybersecurity through a portfolio of platforms that can be centrally managed via the cloud. It’s not clear how much organizations are centralizing management of security across their software supply chains and production environments, but Arora noted that interest in consolidating security vendors is high as organizations look to reduce the total cost of cybersecurity.
In the meantime, organizations of all sizes are looking to employ DevSecOps best practices to better secure software supply chains in the wake of a series of recent high-profile breaches. In addition to scanning code for vulnerabilities, many of those organizations are starting to realize the tools and platforms used to build applications are also vulnerable to cyberattacks. The goal of those attacks is to insert malware that will manifest itself in any number of downstream applications that are eventually deployed in a production environment.
It’s not yet apparent just how compromised those tools and platforms may be, but it’s clear software consumers are moving toward holding developers more accountable for vulnerabilities. The best-known example of those requirements is an executive order issued by the Biden administration that will require federal agencies to include software bills of materials (SBOMs) that list known vulnerabilities. Many enterprise IT organizations are expected to adopt similar requirements.
One way or another, however, the tools and platforms that make up a software supply chain, along with the code they produce, are going to be subject to much greater scrutiny than ever before.