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: Herbert Diess is out at VW because software is hard (yo), fiber optic cable is hard to find, and the guy who said LaMDA was sentient is dumped by Google. (more…)
When it comes to realizing the promise of 5G, we’re still a few years away. Under the hood, though, the rollout of 5G infrastructure and the new applications 5G will enable—from AR and VR to new drone capabilities and beyond—will drive dramatic changes in infrastructure demands, starting with the public cloud.
In the 5G era, many of the applications that will become possible and take advantage of this network infrastructure will require a tremendous amount of data to be moved and processed—whether for a connected car, video surveillance with real-time analytics, or AR/VR—so much so that the data needs can’t really be solved at the responsiveness that these applications will demand from the centralized public cloud as we know it. As 5G creates a new ecosystem, a lot of these applications are going to be built in new ways and rely on the attributes of edge clouds: Edge computing delivered as a cloud-like service. Underpinning it will be cloud-native architectures and other highly automatable and flexible infrastructure to help make it a reality. Let’s take a look at some of the key elements.
SaaS companies building applications in the public cloud today are used to self-service, elastic infrastructure. You don’t have to think about hardware, you pay per use, there are APIs to take advantage of, and most importantly everything is highly automatable and flexible. More than likely, you need only think in terms of a handful of centralized locations as you build—a site on the west coast, one on the east coast, one or two in Europe or Asia.
In the 5G future, that will likely no longer be the case. Many new, revenue-generating services will depend on low-latency, high-bandwidth capabilities that enable applications and data processing to get closer to the user or device. Everything from industrial applications, IoT, to immersive infotainment (virtual and augmented reality) to telemedicine and more will be able to take advantage of the 5G network and edge-compute processing to deliver new capabilities and experiences.
Services like these depend not only on connectivity but also on the ability to gather data, process it, and more importantly, move and act on it at very high speeds.
In this new world, you still want the same things from your infrastructure—it needs to be elastic and capable of scaling up and scaling down. And reliability, automation, and agility (the ability to iterate and deploy quickly) become even more important. And it needs to be available and running in many, many more places in order to be close to the customers and devices you are serving. You’re not thinking about three locations across the globe or two or three across the U.S. Instead, you may be thinking about a couple of dozen in one metro area alone. A whole new kind of compute environment has to be built around that, as well as a cloud infrastructure environment.
5G environments will require very flexible infrastructure that can be highly automated, repurposable, and usable in very generic ways. If you are building metro, point-of-presence data centers all over the country, it is not cost-effective to use highly specific infrastructure for each application in each site; it is too limiting in flexibility and too onerous to manage at scale.
One aspect of the infrastructure challenge is that service providers still rely in part on monolithic, traditional applications that tend to run in physical or virtualized environments to make them deployable, controllable and able to be automated. But newer applications are being designed with a different technology stack based on containers.
With applications that live in both areas, flexibility across VMs and containers is a must. As a result, rollouts of 5G will employ a multimode infrastructure, combining both virtual machines and containers in order to support both legacy and modern applications. The goal: Easy automation everywhere.
Virtualized and container environments will need to live and operate in concert with one another. They both require automation, but because each has its own needs it’s important to choose a technology stack and approach that will incorporate and work with both.
While virtual machines and virtualized network functions (VNFs) are more prevalent today, that won’t remain true for long. As carriers move to microservice architectures that drive continuous improvement and speed time to value, adoption of CNFs is growing.
Since it is still early days for 5G use cases, architecture flexibility will allow carriers to pivot toward any killer apps that emerge. Data-centric infrastructure that can deliver both performance, agility and flexibility is essential.
As we look out at the possibilities for 5G, it’s helpful to think back to the early 1990s. With AOL dial-up and a 2400 baud modem, you could email, surf the web (though it was painfully slow) and play a few games. The advent of broadband ushered in entirely new applications and use cases like e-commerce and media streaming and drove the infrastructure changes to support them. 5G presents the same type of potential for sea change that will open up a whole new world of innovations for the consumer and the enterprise.
Let’s face it, tools for infrastructure-as-code (IaC) configuration management may be vital, but they’re difficult to use. But what if it’s not so much the tools themselves as it is our understanding of them? What if we looked at provisioning and configuration systems differently and did so using vocabulary that was less confusing and more common?
Simply put, we’d gain a greater understanding of these tools—and, therefore, they would be simpler to use—if the terminology was simpler. Reframing these complex tools would not only allow us to make greater sense of this realm, but we’d be more effective in addressing the DevOps and software issues we all experience.
Software engineering encompasses all the actions developers take to create software and technology products. This typically entails writing code, testing it and making sure it satisfies the original requirements for users. Operations is the practice of ensuring those software systems are ready to go and will be able to serve users on a day-to-day basis. Operations engineers aren’t as focused on writing new code as developers are; instead, they are focused on how existing software (mis-)behaves in existing systems.
Now let’s cover some other key phrases we use and hear all the time in DevOps.
Forward engineering means creating a system based on requirements that exist for that system. It entails first building a model, implementing it in software, then configuring and deploying it into operation. While the goal is for the new system to closely match the original requirements, the modeling process can be ambiguous, causing a system to perform in unanticipated ways. Furthermore, over time, the system itself may differ from the original model due to interaction with its environment. Consider that some parts can change the configuration of other parts; procedures performed by engineers shift the system state or configuration, too.
Unfortunately, forward engineering offers no feedback with regard to the eventual success or failure of the product during the model creation process. These models and the subsequent software are created first and then deployed to test for success. Such a system can only provide feedback later based on its behavior, which can then be used to improve and build new models.
Reverse engineering calls for understanding existing systems, usually by first creating a partial mental model by inspecting such a system and then using it to plan any modifications. Often, changes are made directly to the system without always fully understanding how it works. Feedback for changes is fast because putting the system through its paces and inspecting the results is relatively simple, easy and cheap to do. A good example of reverse engineering is software security professionals who scan network services or memory to identify anomalies and exploitable gaps and then try to manipulate their content for instant feedback.
Then there’s infrastructure-as-code (IaC). This modeling technique began with declarations about how server operating system content should appear and was later adapted for the purpose of laying out and configuring cloud resources using API calls. While many vendors and products have come and gone, most tools have been declarative—with good reason.
With declarative tools, you specify how things should appear without explicitly showing how you’ll get there. Why? It’s the easiest way to create models, templates and maps because engineers only have to declare how things should look, not get them into the correct form or place to actually do so. The emphasis is on evolving from iterative improvements that take place over time.
Another feature of declarative IaC tools is idempotence, which means repeating an action multiple times with consistent results; the system only changes when it detects deviations from the model. This can be compared with the imperative approach, which requires developers to first find all the differences between a model and system and then write each step that’s necessary for the system to match the model.
Declarative IaC tools eliminate the need for developers to write an implementation for these changes manually. These tools save thousands of labor hours by publishing templates that can be used repeatedly to build identical systems with less time and effort. The problem is that declarative tools rely on a forward engineering mindset—meaning there’s no way to get feedback from a live system—leading to many complaints from users.
Configuration drift is what happens when a declarative forward engineering model no longer matches the state of a system. It can happen when a developer changes a model’s code without updating the systems built using that model. It could also be the result of an engineer that does exploratory ad-hoc operations and changes a system but fails to go back into the template and update its code.
Is it realistic to ban operators from ad-hoc exploration? Actually, some companies have policies forbidding any operator or developer to touch a live production environment. Ironically, when a production system breaks, it’s the first rule overridden: Ad-hoc exploration is welcomed by anyone able to get to the bottom of the issue.
Engineers who adopt IaC usually don’t like the work that comes with remodeling an existing system. Still, because of high demand fueled by user frustration, there’s a tool for every configuration management language—they just fail to live up to engineer expectations. The best-case scenario is that an engineer can use a reverse-engineered template to copy and paste segments into one but will need to manually write it elsewhere.
What is needed is a new type of IaC tool. These must integrate reverse engineering at their core and allow feedback from living systems to update the very models that created them. In doing so, operators can adopt an ad-hoc change or simply revert back to the system as it was declared in the original model.
Yet, today’s standard tools fall short of this goal, and aren’t much good for helping engineers solve system operations issues. True, there are those capable of auditing templates and singling out misconfigurations and mistakes. Still, while helpful, the greater value would be the ability to review a living system, not just the templates that engineers initially used to create it.
We have monitoring and observability tools and IaC tools, but in between them is a wide chasm. For effective DevOps, what’s required is a new breed of IaC tool, one that integrates reverse engineering practices that supports operations engineers and enables companies to bridge any development gaps.
A new study from Stanford University found that it takes 75 gigajoules per year of energy for a person to have a good, long life, but the average American uses nearly four times that amount: 284 gigajoules/year. In fact, the U.S. consumes 17% of the world’s energy while accounting for only 4% of the population.
It’s not a new call to action that we need to do more to reduce our energy consumption. Corporations are starting to take action by implementing environmental, social and governance (ESG) programs. However, digital infrastructure is a huge contributor to energy utilization. The collective cloud now has a bigger carbon footprint than the airline industry. So, when enterprises are evaluating and managing cloud costs, they have to look beyond the economic costs and also consider the environmental cost and potential harm to the planet—they have a responsibility to use cloud services efficiently with zero waste.
So, the questions to ask are: How do you know if your organization is using the cloud as efficiently as possible, and how do you prove the software you’re developing is cloud-efficient? An organization can have a major competitive advantage if they make cloud cost efficiency a priority for all teams involved—especially given the ongoing climate crisis and current market downturn. Below are three basic rules to ensure continuous cloud cost efficiency.
The cloud is a service that gets turned on and off, like a light switch. And, like a light switch, it should also be turned off when not in use. Also, as is the case with separate bins for trash and recyclables, organizations shouldn’t reserve large instances when a medium-sized instance will be acceptable. How much cloud is required will change over time, but it’s rooted in knowing who—which team, application, etc.—is using which cloud resource for what purpose at any given time. Ideally, no cloud resource should be left untagged and no cost unallocated, even for shared resources. Organizations can then focus on eliminating unused and underutilized resources.
Take advantage of tools that measure the carbon footprint of cloud usage. When organizations can reduce their footprint, it saves money and impacts other business metrics, such as cost of goods sold (COGS), employee satisfaction and even customer experience. Experiment with different technical levers and see how they impact the cloud costs—this will also lead to smarter choices. By empowering engineering teams with cloud cost data, organizations will enable greater efficiency from the beginning of the software development life cycle.
Cloud consumption will increase as a business grows—but is it growing efficiently? According to the Flexera 2022 State of the Cloud Report, optimizing usage is the top cloud initiative for the sixth year running, as cloud costs can spiral out of control quickly for a growing SaaS business. With accurate budgeting and forecasting capabilities, organizations can take advantage of long-term savings plans and reserved instances with confidence. In addition, addressing cost anomalies quickly will assist in the stabilization of growth. Not to mention the fact that cloud cost management products offer automated recommendations; the faster users act on cost-cutting alerts, the more money and energy will be saved in the long run.
When an organization is reviewing cost reports and deciding which infrastructure changes to make, they should also give engineering teams real-time visibility and control over cloud costs so they can act faster and more ethically. With a corporate focus on cloud cost efficiency, organizations can brag about their reduced carbon footprint and be confident that their “Go Green” attitude is benefiting customers, employees and shareholders and, above all, the planet.
Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.
Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.
Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.
Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.
Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.
Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.
Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.
Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.
It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.
At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.
Scribe Security today unveiled a Scribe Integrity tool that scans software artifacts to make sure they comply with IT organizations’ security policies before they are integrated into an application.
The Scribe Integrity tool authenticates open source and proprietary source code before it is uploaded into a build. It assumes that all artifacts are “guilty” until they can prove their innocence, said Rubi Arbel, CEO of Scribe Security. That approach makes it possible to ensure the integrity of the overall software supply chain is maintained in a way that doesn’t adversely impact the productivity of developers, he added.
In addition, the company launched GitGat, an open source policy-as-code tool based on Open Policy Agent (OPA) agent software that enables DevOps teams to periodically run reports that surface insights into the security posture of code residing in GitHub repositories.
Arbel said that, in time, GitGat’s reach will be extended to add support for additional continuous integration/continuous delivery (CI/CD) platforms.
The first release of Scribe Integrity addresses Node.js code and the npm package manager with support for additional types of code planned.
The Scribe Integrity tool also identifies all dependencies to enable DevOps teams to generate an accurate software bill of materials (SBOM) as each software artifact is included in the application, he noted. That’s critical because it enables developers, IT operations and cybersecurity teams to simultaneously see what artifacts, including containers, make up an application, noted Arbel. In the future, the company plans to make available a Scribe Hub that will make it easier to share insights into those software artifacts, he added.
A series of high-profile security breaches clearly demonstrated cybercriminals’ skill at injecting malware into software artifacts and compromise any application that incorporates that artifact into an application. That malware can then be activated at some later date to potentially compromise any number of downstream applications.
Those incidents resulted in a greater appreciation for DevSecOps best practices to maintain the integrity of software supply chains. The issue that DevOps teams are trying to address is how to build more secure applications without slowing down the rate at which those applications are built and deployed. As such, DevOps teams are adding tools to the application development process that make it easier for developers to scan code before it is included in an application and verify the integrity of any software component that becomes part of a DevOps workflow.
It’s unknown how long it may be before the adoption of DevSecOps best practices has a meaningful impact on application security. However, waiting to focus on security until after an application has been deployed is way too late. Cybercriminals today can discover flaws and misconfigurations in applications in a matter of minutes. As more applications are deployed, developers can find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building applications that are secure from the ground up is clearly required.
The intersection of CI/CD and network automation has grown substantially over the past few years. Network teams have seemingly reached the point in their automation and orchestration journey where it has become critical to implement a strategy to manage the testing, version control and deployment of both network changes and automation assets.
While CI/CD has grown in popularity, there are—at least on the surface—many differences in the types of pipeline implementations to which network teams want to apply the technology: Different tooling, different scenarios and different problems being solved. Despite the seeming disparities, there are some key themes that are consistent throughout most pipeline implementations. For instance:
Network teams either want to develop pipelines to better manage specific changes to the network or they want to use pipelines to better manage the testing and deployment of automation and orchestration assets like workflows or scripts. Where initially those teams may have turned to network infrastructure-as-code (IaC), a significant (and growing) number are investing in automation asset pipelines.
The trust and resources being dedicated to these pipelines is just one of a growing number of indicators that automation and orchestration solutions are maturing and moving beyond initial implementations to large-scale, business-as-usual technologies.
A close examination of recent pipeline developments provided more clarity about the respective strengths of CI/CD tooling and network automation tools for network change management and life cycle—GitLab, GitHub, Jenkins and CircleCI to name just a few. Most network teams would prefer to stick with a “right tool for the right job” philosophy, wherein the best tool for any given task can easily be integrated into an overall solution.
In this context, the “right tool” philosophy looks at pipelines and at network automation/orchestration tools to identify what they do best. Then, a strategy is developed that maximizes the benefit of both technologies. Using this approach, teams can avoid the pitfalls of trying to solve everything with one or the other, leading to a suboptimal process.
Some good current rules of thumb are based on two simple points:
By integrating both technologies into a common pipeline, network teams can get the best of both toolsets.
The example below illustrates an integrated model where network automation tools provide the engineering logic for the generation, testing and deployment of configuration changes, while the CI/CD tools (represented by the orange arrows) carry the activities through a repeated, automated process, ensuring that the changes go through a consistent path with proper version management, approvals and testing. Multiple teams have successfully implemented this model and they are beginning to iterate their solution to incorporate their unique experiences and improvements.
The widespread expectation from the industry is that, in addition to the integration of CI/CD and automation into a common pipeline, we will begin to see other indicators of maturation of orchestration and automation. Some of these are areas that are already taking shape, such as the shift in skillsets and competencies outside of traditional CLI-centric engineering toward DevOps and CI/CD skills, or the growing importance of quantifying the business impact of automation and orchestration.
Styra, Inc. today launched an authorization service based on the Open Policy Agent (OPA) software that can be invoked via an application programming interface (API).
Torin Sandall, vice president of open source for Styra, said the Styra Run cloud service will make it much simpler to embed enterprise-grade authorization capabilities within applications. Today, developers spend too much time building, maintaining and operating their own authorization platforms to manage permissions across multiple applications.
In addition to enabling developers to access pre-built OPA logic, Sandall noted the service also offloads storage and global replication of end-user permissions data to a cloud service.
The service itself currently runs on Amazon Web Services (AWS), but Styra plans to make the service available on other cloud platforms in the future, he added.
OPA makes use of a general-purpose policy enforcement engine that developers can embed within applications using the Rego language. OPA is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF) and is gaining traction among cloud-native application developers. OPA provides a means to enforce compliance-as-code across a wide range of microservices that now routinely access a wide range of distributed data.
However, Styra Run should make OPA more accessible to a wider range of organizations, especially those that are looking to shift responsibility for security and compliance further left toward developers as part of a set of DevSecOps processes, noted Sandall. Developers that don’t have a lot of compliance expertise can now rely on a cloud service that enables them to focus more of their time and effort on writing code, he added.
The arrival of Styra Run also comes at a time when more organizations are reviewing their software supply chain processes in the wake of a series of high-profile security breaches. It’s not clear to what degree compliance and cybersecurity teams have developed an appreciation for OPA, but as more organizations embrace compliance-as-code, the pressure on those teams should decrease as those applications are inherently more secure than legacy applications.
There will, of course, be some developers that prefer to embed OPA into applications themselves, but a cloud service accessed via API will be the path of least resistance for most developers building software-as-a-service (SaaS) applications, said Sandall. The issue may simply be making developers aware that another low-latency option exists; one that doesn’t require them to deeply master the Rego programming language for the sole purpose of achieving compliance, he added.
Regardless of approach, the general expectation going forward is that applications will more easily be able to meet a wide range of compliance mandates without requiring IT teams to deploy and maintain dedicated compliance infrastructure. As such, there may soon come a day when any application that doesn’t use some type of compliance-as-code framework will simply be rejected out of hand.
Rezilion today announced general availability of a platform that enables DevOps teams to better prioritize remediation efforts by identifying which vulnerabilities both run in memory and actually impact a class or function that can be executed.
Liran Tancman, Rezilion CEO, said the biggest DevSecOps challenge organizations face today is that the bulk of vulnerabilities that developers are tasked with remediating don’t constitute a significant cybersecurity threat.
Rezilion has created a searchable proprietary next-generation vulnerability database (NGVDB) that identifies which issues impact specific classes and functions. That capability enables DevOps teams to de-prioritize close to 95% of software vulnerabilities, said Tancman.
In addition, the Rezilion platform will surface remediation suggestions that lower the amount of disruption and/or cost, he said. A fully-automated remediation capability, for example, will automatically upgrade and test vulnerable software components and packages within a continuous integration (CI) pipeline that were found to be exploitable. In the longer term, Rezilion is also working toward surfacing remediation suggestions that might be addressed using an alternative to patching, said Tancman.
The Rezlion platform is also integrated with IT service management platforms such as ServiceNow and project management tools such as Jira to make it easier to address vulnerabilities as part of existing workflows, he added.
Most developers today are simply overwhelmed by the number of vulnerabilities that cybersecurity teams routinely ask them to patch, noted Tancman. The goal should be to enable developers to focus their limited time and effort on remediating the vulnerabilities that truly matter to ensure application security, he said.
In addition, developers need to have more confidence in the fact that the patch they are being asked to make won’t break their existing applications, added Tancman.
Vulnerability prioritization is, of course, at the heart of the long-standing divide that exists between DevOps and cybersecurity professionals. Spreadsheets filled with long lists of vulnerabilities are regularly created, but there is usually no context provided in terms of how severe a threat any given vulnerability poses. 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.
Naturally, developers are going to allocate most of their time to creating new applications and features. For any DevSecOps initiative to succeed, it’s critical to ensure optimal use of the time allocated to remediation. Cybersecurity teams will continue to compile lists of vulnerabilities, but that list can now be triaged in a way that causes the least amount of friction.
In the wake of a series of high-profile security breaches, there is now more focus than ever on securing software supply chains. The challenge is to find a way to better secure applications both before and after they are deployed in a production environment. There will always be vulnerabilities that are discovered after an application has been deployed. However, just because a vulnerability exists, that doesn’t mean it’s exploitable. The trouble with application security today is that, all too often, remediation efforts turn out to be a waste of time.
GitGuardian has expanded its ability to secure code repositories by providing deeper integration with GitHub.
Ziad Ghalleb, product marketing manager for GitGuardian, said the results of security scans are now provided in the context of pull requests alongside suggestions for remediating issues.
The company also expanded developer onboarding options by adding an application programming interface (API) key provisioning mechanism integrated with its command line interface (CLI) in addition to making it easier to configure that CLI.
Finally, GitGuardian extended support for role-based access controls (RBAC) to its platform so that team members can be assigned different permissions levels for incidents based on their role.
GitGuardian makes it possible to scan source code to detect API keys, passwords, certificates, encryption keys and other sensitive data in a code repository in real-time. Developers building an application often make secrets easily accessible as plain text for the sake of convenience. However, when those applications are deployed in a production environment, developers often forget to delete these secrets. Cybercriminals know to scan for these secrets to make compromising an application environment easier.
A recent GitGuardian report found a typical company with 400 developers would discover 1,050 unique hardcoded secrets when scanning its entire codebase. Each secret had 13 different occurrences, which meant the effort required to remediate those associated vulnerabilities would be considerable, the report noted.
Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. GitGuardian makes it simpler to achieve that goal within the context of a set of DevSecOps best practices by integrating with GitHub with a single click, said Ghalleb.
It’s still early days as far as adoption of DevSecOps best practices is concerned, but it’s clear more responsibility for application security is being shifted left toward developers. The challenge is many developers still lack the tools required to make sure applications are secure before they are deployed in production environments.
Naturally, the earlier an application security issue is resolved the less costly it is to fix. The problem with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers there is an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have secrets management issues could be staggering.
One way or another, it’s only a matter of time before more of those issues are surfaced. In the meantime, DevOps teams can reduce the number of applications that might have this issue by making it easier to discover secrets within applications before they are deployed in production environments. After all, the only thing worse than a secret being discovered by a cybersecurity team is having one uncovered by cybercriminals that use it to wreak havoc.