Category: Social – Facebook
-
Data Reliability Needs to Shift Left
Data pipelines feed and transform data for consumption and are increasingly growing in complexity. As enterprises continue to add data sources, they run the risk of breaking their data pipelines due to data errors, flawed logic or insufficient resources for processing. The challenge for every modern data team is to establish data reliability as early as possible in the data journey and to create optimized data pipelines capable of performing and scaling to meet the business and technical needs of the enterprise. In the context of data observability, “shift left” refers to a proactive approach that incorporates observability practices during the early stages of the data lifecycle. This concept is borrowed from software development methodologies and emphasizes addressing potential issues and ensuring quality from the outset.
Shifting left involves integrating observability practices and tools into the data pipeline and infrastructure from the beginning. This approach avoids treating observability as an afterthought or applying it only in later stages to identify and resolve data reliability, integrity, and performance issues as early in the development process as possible, minimizing the likelihood of problems cascading downstream.
The Economic Impact of Poor Data
To effectively manage data and optimize data pipelines, it is crucial to detect and address data incidents as early as possible within the supply chain.
The “1 x 10 x 100 Rule” is applicable in a variety of processes, including software development. It states that the cost of fixing a problem increases exponentially, depending on the stage at which it is detected. The rule can be extended to data pipelines and supply chains, where it suggests that detecting and rectifying a problem in the data landing zone (i.e., where source data is fed) incurs a cost of $1, whereas identifying and addressing the issue in the transformation zone (i.e., where data is transformed into its final format) increases the cost to $10. If the problem is only detected in the consumption zone (where data is in its final format and is accessed by users), the cost rises significantly to $100.
Shift Left Data Reliability
The process of identifying data pipeline issues has become more challenging for data teams as data supply chains continue to evolve and grow in complexity, mainly resulting from the following factors:
● Expanding sources: The number of data sources (such as Databricks, Snowflake, Redshift, Teradata and many others) being incorporated into the supply chain has significantly increased. Organizations now integrate data from a wider range of internal and external sources, contributing to the complexity of data management and processing.
● Advanced data transformation logic: The logic and algorithms used to transform the data within the supply chain have become more sophisticated. Complex transformations and calculations are applied to raw data to derive meaningful insights, necessitating robust systems and processes to handle the intricacies involved.
● Resource-intensive processing: The processing requirements for data within the supply chain have significantly escalated. With larger volumes of data and more complex operations, organizations must allocate substantial computing resources, such as servers, storage and processing power, to handle the data processing workload effectively.By proactively addressing data incidents at an early stage, organizations minimize the potential impact and cost associated with data issues. This not only ensures the reliability and accuracy of data consumed by users but also safeguards the integrity of downstream processes and decision-making. Ultimately, the shift left approach to data reliability promotes efficiency, reduces costs, and enhances overall data quality and trustworthiness.
How Can Data Teams Shift Left?
To effectively shift left in your data reliability solution, certain capabilities are crucial; these include:
● Early Data Reliability Checks: Conduct data reliability tests before data enters the data warehouse and data lakehouse. This ensures that bad data is identified and filtered out early in the data pipelines, preventing its propagation to the transformation and consumption zones.
● Support for Data-in-Motion Platforms: Enable support for data platforms like Kafka and monitor data pipelines within Spark jobs or Airflow orchestrations, which enables real-time monitoring and metering of data pipelines.
● File Support: Perform checks on different file types and capture file events to determine when incremental checks should be performed.
● Circuit-Breakers: Integrate APIs that incorporate data reliability test results into your data pipelines, which can halt data flow when bad data is detected. By preventing the spread of bad data, circuit breakers protect downstream processes from being affected.
● Data Isolation: Identify and isolate bad data rows, preventing their continued processing.
● Data Reconciliation: Implement data reconciliation capabilities to ensure consistency and synchronization of data across multiple locations.Shifting left your data reliability practices empowers data teams to focus on innovation, reduces costs, enhances data trust and enables agile business processes. Embracing this approach makes data more usable and resilient and delivers a more robust and reliable data ecosystem that supports informed decision-making and drives organizational success.
-
Five Great DevOps Job Opportunities
DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.
Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.
Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.
The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.
We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:
CareerBuilder.com
Johns Hopkins University Applied Physics Laboratory
Laurel, Maryland
Automation/DevOps Engineer
$160,000Dice.com
SVMT, Inc.
Fort Meade, Maryland
Systems Engineer -DevOps
$140,000 to $170,000Indeed.com
Hadron Industries
Remote
Infrastructure Engineer
$120,000 to $200,000SimplyHired.com
Tesla
Fremont, California
DevOps Engineer – PowerShell
$120,000 to $152,000LinkedIn
Discover Financial Services
Riverwoods, Illinois
Principal Infrastructure Engineer
$101,000 to $172,000 -
Survey Sees Spike in Untested Code Leading to a DevOps Crisis
A survey of 500 developers conducted by the market research firm OnePoll on behalf of Sauce Labs found more than two-thirds (67%) admitted they pushed code into a production environment without testing, with more than a quarter (28%) acknowledging they do so on a regular basis.
More troubling still, 60% also admitted using untested code generated by ChatGPT, with more than a quarter (26%) doing so regularly.
More than two-thirds of developers have also merged their own pull requests without a review, with 28% confessing they do so often or very often.
Finally, the survey found three-quarters of developers admitted to circumventing security protocols, with 39% of developers doing so routinely. A full 70% also acknowledged using a coworker’s credentials to circumvent restrictions for access to data and/or internal systems, with 41% doing so regularly.
Jason Baum, director for community for Sauce Labs, said that while the survey makes it clear there are a lot of instances where best practices are being ignored, much of this behavior can also be attributed to the amount of extra work developers now routinely take on. The survey found more than three-quarters of developers (77%) have, for example, assumed more responsibility for testing in the last year.
The issue organizations need to evaluate is how much of this is due to developers being lazy versus looking for shortcuts in an era where too many tasks have been shifted left to developers and which they are not able to absorb, said Baum. Many organizations might have better outcomes if more tasks were automated within the context of a DevOps workflow to reduce the amount of cognitive load being placed on developers, he added.
The simple fact of the matter is there is a fundamental skills gap, said Baum. The number of so-called full stack developers capable of managing the entire software development life cycle is relatively small, he noted.
In the meantime, the amount of code generated is steadily increasing as developers take advantage of generative AI platforms to improve productivity. The challenge is the large language models (LLMs) being used to create that code were trained using examples of code pulled from across the web. In addition to having known vulnerabilities, it is of varying quality. In fact, those LLM platforms will frequently generate different snippets of code that vary in quality at different times.
DevOps teams that are responsible for managing the overall codebase are now finding their pipelines are becoming overwhelmed. That’s becoming especially problematic at a time when governments around the world are crafting legislation that will hold organizations more accountable for the security of the applications they build and deploy.
Eventually, AI will also be used to increasingly automate DevOps workflows and should enable software engineers to keep pace with the accelerated rate at which code is being written. In the longer term, LLMs that have been trained using vetted code will also generate higher quality code than a general-purpose LLM such as ChatGPT. In the meantime, however, massive amounts of untested code will likely create a series of downstream cascading events that will come back to haunt DevOps teams in the months and years ahead.
-
Survey Surfaces Benefits of Applying AI to FinOps
A survey of 200 enterprise IT decision-makers published this week found organizations that have infused artificial intelligence (AI) into financial operations (FinOps) workflows to reduce IT costs are 53% more likely to report cost savings of more than 20%.
Conducted by the market research firm Foundry on behalf of Tangoe, a provider of tools for managing IT and telecommunications expenses, the survey found organizations that embraced FinOps without any AI capabilities averaged less than 10% in cost savings.
The top three drivers for adopting FinOps/cloud cost management programs are the need to increase cloud resource production and performance (70%), reduce budgets (60%) and rising costs (58%), and simpler overall program management (50%), the survey found. Major benefits included productivity savings (46%), cost savings (43%) and reduced security risks (43%). Nearly two-thirds of respondents cited service utilization and right-sizing of services as another reason to embrace FinOps.
FinOps describes a methodology for embedding programmatic controls within DevOps workflows to reduce costs. In the face of increased economic headwinds, IT leaders are looking to reduce cloud computing costs, but it’s turning out to be more challenging than many of them anticipated. Cloud infrastructure is typically provisioned by developers using infrastructure-as-code (IaC) tools with little to no supervision. The reason for this is developers have long argued that waiting for an IT team to provision cloud infrastructure took too long. Developers would be more productive if they just provisioned cloud infrastructure themselves.
However, after ten years of cloud computing, it’s become apparent there are a lot of wasted cloud infrastructure resources. Developers who don’t pay the monthly bills for cloud services tend to view available infrastructure resources as essentially infinite. It’s usually not until someone from the finance department starts raising cost concerns that developers even become aware there might be an issue.
The challenge is that adopting FinOps best practices is not quite as easy as it might seem. In fact, more than half (54%) of survey respondents cited challenges in building the right process and human support systems for FinOps into workflows that have been in place for years.
Chris Ortbals, chief product officer for Tangoe, said the simplest path to FinOps is to rely on a software-as-a-service (SaaS) platform designed from the ground up to leverage AI to help IT teams manage cloud computing and telecommunications expenses both before and after applications are deployed. Each DevOps team will ultimately need to determine how much they will implement metrics to foster more efficient consumption of cloud computing resources. The more aware of those costs DevOps teams are, the more likely that better decisions about what types of workloads should be run where and, just as importantly in the age of the cloud, at what time, given all the pricing options provided.
Developers, of course, tend to jealously guard their prerogatives. Convincing them to give up their ability to provision cloud infrastructure on demand is going to be a challenge, at least until someone makes it plain how much all those cloud instances wind up costing the organization each and every month.
-
Netlify Unfurls Composable Jamstack Framework for Web Apps
At its Compose 2023 conference, Netlify today launched a composable framework that promises to make it simpler to build web applications spanning multiple backend services.
Netlify CEO Matt Biilmann said the Netlify Composable Web Platform provides a more holistic approach for loosely coupling the frontend of a web application with backend services that can be swapped out as needed.
The goal is to make it simpler to unify content, data sources, code and infrastructure at a higher level of abstraction while providing development teams with a maximum amount of flexibility, he added.
The Netlify Composable Web Platform consists of Netlify Core to manage workflows, Netlify Connect to access content and data sources and Netlify Create to build applications using JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as Jamstack, framework.
Collectively, the tools will enable development teams to move away from monolithic web applications that are more difficult to update and maintain, noted Biilmann. Instead, development teams can compose applications faster using a framework that automates many of the underlying processes that conspire to slow down application development, he added.
In the face of challenging economic headwinds, interest in improving developer productivity is rising because organizations need their existing teams to consistently deliver applications faster. Most organizations can’t afford to continue expanding development teams when the current processes relied on to build software result in developers spending only a quarter of their time writing code.
There is also a greater need for collaboration using a framework that enables different members of a development team to build elements of an application in isolation from one another without impacting the entire application. Each organization will need to decide for itself whether it wants to make applications from multiple services, but at a time when the speed of adding new capabilities to an application is core to an organization’s ability to differentiate itself, the need for a different methodology for building applications has never been more apparent.
There is, of course, no shortage of frameworks for building web applications, but DevOps teams have a vested interest in making sure that whichever one is adopted is based on a modern architecture. The time and effort required to support monolithic applications in an era where new capabilities need to be added regularly has become cost-prohibitive. The challenge is finding a framework that enables developers to quickly build applications that can be deployed within the context of a DevOps workflow that typically needs to support applications being developed in multiple programming languages.
It’s not clear who inside IT organizations is driving adoption of composable frameworks for building the next generation of applications, but as more organizations become dependent on software, legacy approaches to building monolithic applications have become antiquated. The good news is that in terms of the developer talent pool, there are large numbers that are already familiar with multiple variants of the JavaScript programming language. The challenge, as always, is making sure that whatever code finds its way into a production environment is actually reliable enough to consistently drive a business process.
-
Preparing for the Shift to Platform Engineering
Platform engineering is one of the hottest trends in the software delivery world and is expected to represent the next evolution of DevOps. According to Gartner’s 2023 study of top strategic technology, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery by 2026. What used to happen in one day in the developer world now needs to happen in five minutes. With high pressure for organizations to scale operations quickly, especially in a marketplace clamoring for the benefits of artificial intelligence (AI), automation is increasingly important in platform engineering. It reduces manual errors, streamlines the development process and boosts growth and efficiency. As technology advances rapidly, it becomes more critical for organizations to proactively navigate newly emerging trends within platform engineering to remain competitive. The keys to successful platform engineering include cloud-native architecture, AI and machine learning (ML), and evolving tools that use intuitive interfaces and pre-built components to create functional applications.
Platform Engineering is the Natural Progression of DevOps
Platform engineering expands on the practices of DevOps by moving development out of silos and taking a collaborative, bird’s-eye view of an organization’s technology. Platform engineering is built on a foundational infrastructure that enables self-service capabilities so developers can deploy code faster, more reliably and more securely. While platform engineering represents the next wave of change in DevOps, it’s essential for leaders and developers to understand that it isn’t a singular technology or approach. The shift to platform engineering also represents a cultural shift for developers and leaders to address the needs, challenges and rapid pace of modern software development by optimizing processes, accelerating delivery and reducing the complexity of operations. For platform engineering to succeed, it’s critical to approach it from the perspective of a technology-driven culture that creates solutions with a developer’s perspective in mind. By seeking to improve the developer experience first, enterprises can achieve better results.
Trends Shaping the Landscape
Platform engineering itself is an emerging trend, but several essential ingredients shape how it will impact businesses today and in the future. For organizations to reap its benefits, understanding these essential trends will keep them ahead of the pack.
Cloud-native architecture is fundamental to modern platform engineering by designing and building applications for cloud environments. Infrastructure-as-code (IaC) is a key component, enabling the automated provisioning and management of resources. Cloud-native platforms like Kubernetes, Terraform or Docker facilitate container orchestration and scaling, while serverless computing isolates infrastructure management entirely. This trend ensures that platform engineering is agile, scalable and cost-effective, with minimal downtime and easier maintenance.
Automation is pivotal in platform engineering, reducing manual errors and streamlining deployment workflows. It allows developers to build, test and deploy software more efficiently, leading to faster and more reliable product releases. In fact, 43.2% of early adopters of platform engineering saw faster product delivery. Automation tools like Jenkins, Ansible and Terraform are commonly used to automate infrastructure provisioning, configuration management and deployment pipelines. Machine learning (ML) models can perform automated troubleshooting by analyzing historical data to identify patterns and predict potential issues, proactively addressing problems and minimizing downtime. This also helps with performance optimization. By using AI that can analyze application performance data, automation takes platform engineering to the next level by suggesting optimizations to improve resource utilization and user experience. AI-powered tools assist in generating code or script, which is vital to reducing development time and human error. ML algorithms empower the security side of platform engineering, a top priority for any developer. It’s possible to leverage automated security tests during development and maintenance, even detecting and responding to security threats in real-time. When AI handles routine tasks, developers are less likely to feel overwhelmed or experience burnout. This allows developers to focus on more creative tasks, complex problem-solving and innovation, resulting in more efficient operations to help them achieve higher levels of productivity, security and consistency.
Evolving development tools that create functional applications using intuitive interfaces and pre-built components increasingly simplify application development and deployment. Low-code and no-code platforms allow developers to create applications with minimal coding effort, utilizing visual interfaces and pre-built modules. Serverless frameworks like AWS Lambda and Azure Functions enable developers to focus solely on writing code. An increasing reliance on and advancement of application programming interface (API) gateways provides a simplified way to manage and expose APIs, enhancing application integration and connectivity. Containerization platforms are becoming similarly powerful tools. Platforms like Docker and Kubernetes simplify application deployment across diverse environments by offering standardized containers and orchestration. Adopting a strategic suite of these evolving tools requires a clear understanding of product goals, organizational goals and developmental capabilities.
How Leaders can Support Platform Engineering
It’s projected that 30% of organizations are currently evaluating the adoption of platform engineering practices, and its prevalence will only grow. While platform engineering’s trends are empowered by digital transformation and new technologies, it’s vital to remember that platform engineering represents a shift in DevOps culture. To effectively support the transition, leaders must commit to a culture of platform engineering. Simply adopting technology isn’t enough. It needs to be backed by a thorough strategy that allows developers to truly benefit from the tools and structures of platform engineering. What does this look like? Success requires leaders and developers to encourage collaboration and break down silos between operations and development teams. It’s possible to build a bridge between developers and operations by committing to cloud migration, creating a centralized platform and investing in collaborative tools and the strategy to back it up.
To engage in platform engineering requires dedication to a collaborative culture instigated from the top, empowered by overall strategic decisions and operations. This includes continued learning for developers to stay on top of new languages, trends, challenges and priorities, internally and externally. Teams are more successful when they utilize performance metrics to track workflows that help them conduct effective maintenance and improve on a consistent and ongoing basis.
Embracing Change is Embracing Progress
In the fast-paced and continuously improving world of software development, it’s easy to think that each wave of technology will replace the last. Of course, experts know this isn’t true. Iteration is vital to advancing technologies, and it’s important to embrace the next iteration of progress to stay competitive. Automation and platform engineering are tools that enable developers rather than replace them. It’s important to note that platform engineering doesn’t mark the end of DevOps. Rather, it takes the core foundations that DevOps has built to the next level to empower developers with self-service capabilities, foster collaboration, enhance scalability, accelerate deployment and instigate sustained business growth.
-
Atlassian Makes Compass IDP Generally Available
Atlassian this week made generally available a Compass developer experience platform through which DevOps teams can employ a software-as-a-service (SaaS) platform to centralize the management of the environments used to create code.
Taylor Pechacek, head of product for Compass at Atlassian, said Compass provides an instance of an internal developer platform (IDP) that is simpler for DevOps teams to set up and maintain.
At its core, Compass provides access to a software component catalog to track, search and discover the component and approved infrastructure that can be used to build and deploy applications.
In addition, templates enable developers to self-service environment setup using a set of policies that provide guardrails to ensure developers follow best practices for provisioning cloud resources and setting up pipelines.
Finally, Atlassian is making available scorecards based on the DevOps Research and Assessment (DORA) metrics defined by Google.
Compass is designed to be integrated with a wide range of continuous integration/continuous delivery (CI/CD) platforms and third-party observability, testing, collaboration and source code management tools, said Pechacek. The goal is to minimize context switching as much as possible for developers accessing the Compass platform, he added.
That approach also provides a level of consistency that both fosters collaboration and makes it simpler to onboard new members to a development team, noted Pechacek.
While IDPs as a concept have been around for some time, they are now central to any effort to embrace platform engineering methodologies to implement best DevOps practices at scale. The issue platform engineering teams need to come to terms with is determining whether they want to build and maintain an IDP versus invoking one provided as a SaaS application.
Regardless of approach, platform engineering teams are trying to strike a delicate balance between centralizing the management of development environments and the ability of developers to innovate by adding new tools to their development environment. Organizations clearly want developers to become more productive by spending less time managing development environments, but many of those same developers tend to jealously guard their prerogatives when it comes to the tools they prefer.
The challenge, of course, is that spending less time managing a development environment doesn’t necessarily mean more code will be written. All it does is afford developers the opportunity to write more code. The issue is that the writing of quality code only really occurs when developers are inspired, but at the very least, configuring a development environment shouldn’t stand in the way of creativity.
It’s not clear how many organizations are embracing platform engineering methodologies, but it’s apparent that more supervision is being brought to how applications are built and deployed within the context of a set of DevOps best practices. The challenge and the opportunity now is to make sure developers buy into, rather than resist, those efforts.
-
Remember: Tools Fail, Too
Between agile development methodologies and DevOps, we have largely removed the stigma of incremental – or even architectural – failures in development, deployment and, more recently, security and operations. Even data management, with increased redundancy and recoverability, has moderated its crazy responses to failures.
This is all good news. Rather than focusing on blame, focusing on fixing the problem and stopping it from happening again are better uses of our time. I’ve pulled some really dumb stunts in my decades of IT (most recently, I trusted a hardware vendor that historically I had trouble with. Unsurprisingly, we are paying that price now. Replacement parts are arriving today–required because they still try to lock you in). So have each and every one of you. No matter how well-trained an individual is, on-the-job training is a fact of life in an industry where most technology innovations last about as long as a cappuccino and we’re asked to know a little bit about a lot of topics to complement our specialty. (I’ve been a dev, worked in ops, as an architect and in security … none of those jobs was doable without working knowledge of the others).
All of that is to say, “We’re admonishing each other less and fixing things more, and that’s good.” I don’t need to point out that there is a balance implied in that statement; most managers are well aware that occasionally a person’s skills/interests aren’t a great fit for the position, and changes have to be made.
But the point of this blog is to say, “We’re really good at acknowledging failure at the granular level, correcting, and making sure it doesn’t happen again. But only at the granular level.”
Yes, the person who championed a tool or system into the organization is going to feel the need to defend it, and we have to acknowledge that this is no different than the developer who made a bad architectural choice feeling the need to defend it. Some tools suck. Some implementations are not great for our use case (I know a group of smart people who can help you figure out which tools do; follow my LinkedIn) and some tools we’ve moved beyond their capabilities.
We make technology decisions for the organization almost every day. Some of them won’t work out in the short term – we’re not terrible about cleaning those up outside of the inimical “executive sponsorship” that sometimes saddles us with suboptimal solutions. But the ones that are kind of successful are the bad ones. We end up limping along when most staff know there are better solutions on the market or even new markets that solve the problems more elegantly.
Most organizations have some form of technology review process–many smaller orgs have that person who makes final decisions, and many larger ones have committees that look across product lines and technologies. Those reviews have only kicked in when something is obviously a hindrance to operations because we don’t have time to muck around with things not broken. And yet, that is not the Agile/DevOps way. We need to be aware of the friction points and smooth things out. I’ve written before about considering standardizing toolchains, and that’s one thing this could evaluate–number of tools versus duplicative effort and disparate training-but a look at any tool included in multiple issues is a good idea, as is “Prove to me this is the best solution”-type conversations.
Keep kicking it; accept that there are reasons that some suboptimal tools will exist, but remove those that provably have better/more efficient solutions for the organization’s needs. I once moved an entire massive data store across platforms because my initial scale-up approach slowly became less appealing than the competitor’s scale-out approach to the same problem. The people I saddled with doing the conversion gave me more grief than my fellow managers, but things worked better afterward. So be honest, but be willing to admit that one risk of the hundreds you take didn’t pan out. And keep the company rolling forward. Your work is critical.
-
GitGuardian Adds Tool for Discovering Secrets in Public Repositories
GitGuardian today added a tool that makes it possible for DevOps teams to search GitHub repositories to determine if application secrets have inadvertently found their way into other applications.
Vikram Ghosh, chief growth officer for GitGuardian, said a HasMySecretLeaked toolset makes it possible to determine if developers have copied and pasted application secrets from one repository into another without permission.
The toolset is based on a private database that houses more than 20 million records of hashed secrets that have been found in public sources, including GitHub.com. Users can query the database by submitting a hashed version of their secret in the search console. The GitGuardian toolset will then search for perfect matches without revealing any other secrets or their locations, said Ghosh.
Alternatively, DevOps teams that have adopted the GitGuardian platform to protect secrets can use a command-line interface (CLI) exposed via a ggshield tool to launch queries. That tool also includes plug-ins for pulling secrets from tools such as HashiCorp Vault and AWS Secrets Manager and staging them in local environments to surface potential leaks. Eventually, HsMySecretLeaked will be extended to add support for additional repositories, noted Ghosh.
Collectively, those capabilities make it possible for organizations to audit how application secrets are being secured, he added.
The GitGuardian platform scans every public commit on GitHub for leaks, spanning API keys, database assignments and developer secrets. In 2022, GitGuardian found 10 million secrets that had been exposed.
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. It’s still early days as far as adopting DevSecOps best practices to secure those software supply chains, but it’s clear more responsibility for application security is being shifted left toward developers and the DevOps teams that support them.
The challenge is that many developers still hard-code secrets in plain text into applications to create shortcuts as software is developed. Unfortunately, many of them forget to remove those secrets before an application is deployed in a production environment. 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 the meantime, cybercriminals have become more adept at using scanning tools to discover those secrets.
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 the meantime, it’s only a matter of time before more stringent regulations require organizations to revisit the security of software supply chains. Countries around the world are debating legislation that would hold organizations much more accountable for the security of the applications they build and deploy.
Hopefully, DevOps teams will implement DevSecOps best practices to get in front of those issues before any fines are levied. But the challenge, as always, is ensuring application security without adversely impacting the rate at which software is currently being built.