devopsy.kinsta.cloud

Tag: supply chain

  • Unifying Partner Ecosystems With a Distributed Ledger

    Unifying Partner Ecosystems With a Distributed Ledger

    Blockchain has become famous in recent years for powering the cryptocurrency craze. But the fundamentals behind blockchain could prove helpful in other areas of the data economy, too. Because, as the value of data rises, so does the need for accurate, real-time data sharing across multiple partners.

    As we saw recently, global trade is surprisingly fickle. If a 1,300 ft long cargo ship can end up blocking the Suez Canal for an entire week, imagine how many data record incongruities the shipping and logistics industries have to sort out each day. Similarly, other partner networks, such as food distribution or airline affiliates, for example, must constantly share data back and forth to remain in business.

    Since a distributed ledger is external yet sharable with partners, it opens some interesting data-sharing possibilities. Similar to merges for collaborative software, partners would retrieve and manipulate the distributed ledger, which would act as a source of truth for status on a physical object or a piece of data. Essentially, this process could reduce manual reconciliation efforts and avoid disputes when something goes wrong.

    I recently spoke with “father of serverless” and AWS Lambda inventor Tim Wagner. Wagner, now heading Vendia, shared with me why he foresees distributed ledgers as the future for real-time, business-to-business data sharing. “Supply chains are surprisingly brittle,” Wagner said. To solve this problem, we need an “automation of that workflow that isn’t centralized any longer,” he said.

    Role of a Distributed Ledger

    A distributed ledger could be especially relevant for a multi-party supply chain. Within multi-partner agreements, data tracking is complex, and many partners struggle to come together. “Companies are struggling for a lack of truth,” said Wagner. “Everyone wants their own copy of the data, but they want it to be locked to what everyone is seeing at the same time.”

    For example, take supply chain management. Suppose an automotive parts manufacturer produces a chassis. They send it to a shipping logistics provider, who then sends it to an automaker to complete assembly of an automobile. If the chassis breaks at some point during these handoffs, whose fault is it? Without a system of record, you open a big problem of distrust, Wagner explained.

    Or, consider an airline ecosystem. Partner airlines must often coordinate multi-carrier flight plans, apply discounts or settle unused travel vouchers. Often, it’s difficult to track the journey of these transactions between organizations. An externalized ledger could help partner airlines follow the route of a single passenger, helping to ease financial settlements.

    “It’s not just about sharing, which is hard enough, but it’s really about sharing with control,” said Wagner. These days, tracing the lineage of data is critical, as is having real-time visibility into an object’s state. A distributed ledger could help these partner ecosystems have a record they can all trust. Wagner describes this as a tamper-proof, immutable record — an “unassailable source of truth.”

    Would This Replace Partner APIs?

    What’s especially interesting to the integration-minded is that the distributed ledger concept could supplant established business-to-business communication models. Over the last couple of decades, most partner integrations have moved to RESTful API connections. One company opens up data access, and another authenticated partner makes HTTP API calls to integrate data into their own application.

    Yet, the issue here is that the API is only a layer on top of a private database owned by the provider. Located behind closed doors, there’s no industry-wide real-time data synchronization. API calls are good for data retrieval and manipulation, but stringing a sequence of thousands of transactions together is difficult, described Wagner. Retaining the time-series integrity of a complex database is a little too much for synchronous calls to handle.

    Instead of opening access to an internal platform via API, Wagner believes that a distributed ledger is a better fit for certain business-to-business machine automation. “Any place where you see API-level protocols developed to maturity is a good sign; there is a good chance distributed ledgers will find greater speed,” he said. “Trying to pull that information through APIs and pray you’re finding the right data is difficult to manage.”

    For example, Wagner referred to how some animal shelters are creating a global repository to avoid siloed records. In doing so, they are making a global animal rescue schema for a unified database that could hopefully help every pet find a home.

    Communicating with the ledger would still involve calls, but likely not your typical RESTful requests. Wagner advocates for the use of GraphQL as a better method to involve clients around changes. With a GraphQL API, stakeholders can query, mutate and subscribe against changes in a distributed system. GraphQL isn’t perfect, but its easy data mechanics make it a Goldilocks-style middle ground between REST and SQL, said Wagner.

    Getting Buy-In

    A synchronized distributed ledger could help resolve disputes and reduce manual checks. But, how do we get buy-in? How can you convince an entire partner ecosystem to align around a distributed ledger as a source of truth?

    Wagner says there is usually a leader or single manufacturer leading the charge. This figure is likely a more prominent, well-respected player in the process. But for a digital ledger system to be successful, it must also satisfy other criteria too, Wagner said:

    • Data schema forethought: Agreeing upon a shared data schema may be a challenge. Ecosystems will require forethought when designing a data model for the long haul.
    • Compliance: There are many new data regulations to consider, such as GDPR, CCPA and PCI. “You can’t blindly copy data the way you used to,” said Wagner.
    • Governance: As enterprises deal with data crossing boundaries, they must apply governance measures to satisfy compliance and maintain security. This governance needs to be tightly associated with data and offer fine-grained control.
    • High performance: A distributed ledger requires operational flexibility for large objects, such as a 5 TB file, noted Wagner.
    • Redaction capabilities: Whereas some partners must see all fields, others may, by law, be limited in what they can view. Thus, a ledger must include the ability to redact fields. Wagner described this as “intentional redaction or visibility control of individual customer records.”

    Of course, different industries are at very different points along their digital journey, some more advanced than others. Change may be easier for, say, financial services supporting ACH payment technology, which Wagner described as being “ripe for natural organic expansion into a data-centric methodology.”

    The Poor Man’s Blockchain

    Tapped into the same feed, an extensive partner ecosystem could use a blockchain-esque arrangement to stay on the same page. This could help reduce manual reconciliation typically handled through email or over the phone.

    Yet, as distributed systems experts are few and far between, implementing such technologies will most likely involve a cloud platform solution, said Wagner. He jokingly calls this the “poor man’s blockchain.” Such a solution must be cloud-friendly, enterprise-focused and easy to integrate and deploy.

    As more and more critical data begins to reside outside company walls, “organizations have to reconstitute that data to work with partners,” said Wagner. A distributed ledger could, in effect, act as a sort of outsourced centralized IT, enabling a data model for serverless environments.

  • Modern AppSec and Supply Chain Attacks – Three Challenges

    Modern AppSec and Supply Chain Attacks – Three Challenges

    The recent news about the SolarWinds breach has focused on the difficulty and challenges a supply chain attack presents.   In the case of what Microsoft is calling “solorigate,” the attackers modified a dll deep inside a trusted application, which was then deployed into over 18,000 enterprises and government organizations, where it would then create a live back door for the attacker to exploit. The Microsoft Threat Intelligence Center (MSTIC) recently published details about how the SolarWinds attack worked and attempted to avoid detection.

    Supply Chain Attacks and API Security 

    In this specific case, the exploit targeted a traditional, legacy application as part of SolarWinds Orion, an IT inventory management and monitoring application. The attack was the result of extensive planning and resources, which appear to be the work of a state actor. The immediate focus must be on mitigation of the current attack. Still, it is also essential to understand that supply chain attacks like this should be considered in the future as modern cloud-native applications become the norm.

    The evolution of cloud-native and modern applications where the functionality is decomposed into microservices, each running independently of each other, presents several new challenges for security and IT professionals to address. Specifically, the underlying application programming interfaces (APIs) introduce new attack surfaces where API security is paramount.  The OWASP API project has enumerated 10 critical API level threats that are substantially more important in the era of modern, cloud-native applications.

    These three trends – microservice proliferation, application change and porous perimeters – create an environment where attacks can flourish and where IT and security teams need to consider revisiting their application security practices and controls.

    Microservice Proliferation

    Inherent in adopting a cloud-native architecture, one characteristic is the decomposition of the monolithic architecture into atomic services. Microservices enable business application teams to operate more efficiently and innovate. This approach also results in a compounding of the number of independent services, where each microservice is a potential source for the injection of a supply chain attack. In the case of microservices, rather than compromising an entire system, an attacker has more opportunities.

    The challenge facing defenders is how to manage the proliferation of hundreds or thousands of new microservices, each with its unique code base and API calls, between services? On one hand, traditional web application firewalls (WAFs) can play a role, attempting to protect the edge, but on the other hand, WAFs do not account for the underlying complexity of the web application and microservices. One key question to ask is, will their rule-based approach adequately detect and prevent this kind of threat?

    Continuous Application Change

    Speed and rate of application improvements and enhancements have accelerated as teams adopt DevOps practices of continuous delivery and continuous deployment. Business expectations of faster delivery and reduced cycle time have naturally led IT teams to embrace and adopt DevOps practices of CI/CD, which, when adopted, lead to significantly shorter cycle times between changes. The industry has seen remarkable improvements in delivery speed; organizations have gone from quarterly releases to weekly and even hourly changes – sometimes, even faster. For example, a team at Goldman Sachs releases every few minutes and Netflix releases thousands of times per day.
    ‍
    In a traditional application where new code is delivered lethargically, it might have been possible to keep up with the pace of change and mitigate security threats. However, in the age of microservices and cloud-native applications, it is unrealistic to maintain full awareness of the application’s state and associated microservices.  Change is happening too fast and at too many internal points for a security leader to adequately manage their risk profile.

    Relatively Porous Perimeter

    Because applications are no longer monolithic installations that reside behind a defense-in-depth fortress, they are much harder to protect. Indeed, the principles of zero-trust are essential when designing and managing modern applications. The reality is that for every microservice (both internal and external), there is a library of interfaces that enable the microservices to communicate with each other (internally), with third-party service providers (externally) and with end users through an established UI.

    Additionally, how many of your applications have a “call home” feature where they communicate health and usage data with their vendor? While many vendors use this information to improve the quality of their service, it is also another potential threat vector to consider.

    The web application firewall and traditional approach to security provide only a degree of protection, as the nature of modern applications encourages the use of SaaS services, third-party services and other resources in the interest of faster delivery. This complicates the challenge of delivering a secure application as well as monitoring it as it is running.

    Suggestions to Address API Security

    We’re still early in the cycle of the SolarWinds breach, and the aftermath will be extensive and expensive, as will the lessons learned as the damage is measured. However, one thing remains true. The threats continue to evolve, which means that security professionals (strike that) IT professionals (because security is everyone’s responsibility) need to renew our focus and commitment to delivering secure, reliable and trustworthy applications.

    There is no perfect protection or 100% secure approach; instead, it is a question of how to establish layers of defense where each layer of security reduces the overall risk exposure. Ultimately, you want to have the ability to:

    • Prevent the risks in the first place (software supply chain and zero-trust architecture) and
    • Detect and react to adversaries who may be attempting to exploit your systems.

    Specifically, here are several recommendations to improve your security posture and lower your exposure:

    1. Invest in processes and tools to help validate your supply chain. A “trust, but verify” approach is critical in the development stages. You should look at tools like Sonatype and others that can help reduce the risks in your software supply chain.
    2. Adopt a zero-trust approach to the design and implementation of microservices.
    3. Maintain awareness and insight into the current state of your APIs and your present risks (too many organizations cannot keep up with the pace of DevOps change).
    4. Augment your perimeter with processes and practices to have “zero-trust, but verify” in production. You need to observe the behavior of each of your microservices and detect anomalous behavior between your microservices.
    • Should microservice A be communicating with microservice B?
    • Is the data flow between microservice A and microservice B typical?
    • Are there suspicious behaviors or patterns that indicate anomalous behavior?

    Traceable.ai helps you detect and react to threats to your cloud-native and modern applications where API security is now mission-critical. If you’re interested in learning more about how you can improve visibility into your modern applications and your overall security posture, the best way to start is to view a quick recorded demo of Traceable.ai.

  • WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource this week announced it has acquired Diffend as part of an expended effort to discover malware that has been deliberately injected into open source software by a contributor acting in bad faith.

    Company CEO Rami Sass said cybercriminals are increasingly trying to compromise software supply chains that today depend heavily on open source projects. The Diffend platform surfaces anomalous contributor behavior that would be indicative of someone trying to compromise the integrity of a project, said Sass.

    Previously, WhiteSource provided a tool that would discover malware that had been inadvertently included in open source software. WhiteSource now plans to add the Diffend tools, now known as WhiteSource Diffend, for free to a portfolio of security tools that many organizations have already incorporated into DevSecOps workflows. Earlier this month, the company raised an additional $75 million in financing that, in part, was used to fund this acquisition.

    As cybercriminals begin to target software supply chains, many of them are taking aim at open source software that is likely to be adopted by a broad spectrum of organizations, noted Sass. The challenge is that bad actors have become adept at embedding malware in software components in ways that are difficult to detect, he said. However, spikes in activity from, for example, a new contributor to the project might warrant additional investigation, Saas added.

    These type of attacks, unfortunately, will require the maintainers of open source software to vet more closely who is allowed to contribute to the project, added SaaS. New contributors that might have once been greeted with open arms need to now be initially met with a modicum of paranoia, Saas said.

    That level of suspicion will be considerably higher if that contributor is located in a country that has a reputation for trying to compromise the security of both adversaries and companies that have intellectual property they might want to surreptitiously acquire.

    In the wake of some recent high-profile breaches involving software supply chain compromises, organizations are revisiting their application development processes. Cybersecurity teams are now asking developers to vet any external code that is incorporated within an application. Most applications regularly incorporate both open source and commercial components that developers assume have been vetted for malware when, in most cases, they have not. The Diffend platform, for example, aided in the detecting of 60 suspicious packages found in Rubygems, an open source platform that makes it easier to package software built using Ruby programming tools.

    It’s unclear how increased inspection of software components may impact application developer productivity. However, given how dependent organizations are on software today, the discovery of malware downstream that compromises the security of the application is potentially catastrophic.

    Sass said it’s doubtful these security concerns will lead to decreased reliance on open source software in general. There is no real alternative for efficiently driving software innovation, he said. The challenge now is finding a way to make sure all that innovation continues to occur as securely as possible.

  • Machine Learning and Predictive Analytics Are Reshaping Manufacturing

    Machine Learning and Predictive Analytics Are Reshaping Manufacturing

    Regardless of industry or vertical, companies everywhere are encountering a new generation of customers with ever-evolving expectations. These new demands are forcing brands to redefine the way they do business.

    Today’s customers overwhelmingly favor the simplicity of subscription models, in which they pay a flat monthly fee for access to a product in the form of a service. For example, consumers no longer buy or rent DVDs; they subscribe to Netflix. And more prefer to use the services of Uber or Lyft over traditional car ownership. As these digital-age consumers enter the industrial workforce in large numbers, they are causing business models to be redefined, leading to an increasing trend toward subscription-based services in manufacturing industries.

    This shift toward a subscription-based business model in the manufacturing industry is being referred to as servitization, wherein manufacturers no longer strictly sell new products but instead sell access to and the outcome those products deliver. This new way of delivering services is forcing manufacturers to shift to subscription-based pricing models, where product-as-a-service is the norm. Manufacturers of complex industrial equipment, because they operate in a B2B environment, can attribute this shift to another major cause: Their customers are also dealing with complex operating paradigms, forcing them to improve productivity and capital utilization. In these scenarios, customers are looking to simplify their businesses and increasingly favor suppliers that can help minimize their risks in operating a profitable business.

    The full realization of servitization, which could take up to 15 years, especially impacts manufacturers’ after-sales service organizations (the service delivered after the initial sale of a product). In today’s current reactive, break-fix service model, the responsibility to maintain and ensure equipment availability falls on the customer. In a servitization model, however, manufacturers own the responsibility of maintenance and repairs and need to focus on maximizing product uptime, since revenue can only be earned when their products are available to generate output in the field.

    Machine Learning and Predictive Analytics in Manufacturing

    The use cases of machine learning and predictive analytics are as varied as the industries within manufacturing. However, there are a few common use cases that apply to most manufacturing verticals, typically grouped under terms such as smart manufacturing, industry 4.0 or industrial internet of things (IIoT).

    1. Predictive Maintenance: Predictive maintenance is the most well-understood and varied use case in most manufacturing industries. Here, data from process monitoring sensors such as temperatures, pressures, flows, vibrations and more are captured in real-time and used in pattern recognition software to detect the earliest symptoms of wear and tear predictive of eventual functional failures. Early detection and prediction can help prevent failures or at least plan for eventual corrective actions leading to minimized downtime. Downtime—especially unplanned downtime—can be a very expensive event, possibly leading to millions of dollars in losses. Some analysts estimate unplanned downtime in certain industries is worth $20 billion.
    2. Process Optimization: Process optimization, in which existing processes are updated and optimized based on historical data, is a critical use case, especially in industries such as power generation, oil and gas refining, petrochemicals and chemicals. In this instance, sensor data feed machine learning algorithms for yield and quality optimization of output components for different combinations and quality of input raw material feedstocks. This also helps with energy efficiency, thus improving sustainability and profitability for these process manufacturers. In the global airline fleet, for example, a 1% fuel savings would save $30 billion over the next 15 years.
    3. Supply Chain and Inventory Management: High levels of raw material, work-in-process and finished goods (e.g., replacement service parts) inventory are one of the highest contributors to inefficient capital utilization for discrete manufacturing industries. Using machine learning to improve raw material and demand forecasts while meeting dynamically changing production goals helps improve capital utilization and supports lean and just-in-time manufacturing production goals.

    In today’s customer-driven world, manufacturers no longer can rely on selling expensive spare parts and services, since these become costs of supporting a single-price subscription. This shift will require manufacturers to completely re-think how they operate—new organization structures and skilled resources, new incentive models, new KPIs to measure success and new processes replacing ones developed over decades and centuries. They will have to become data-driven organizations, investing in technologies to connect and track products, collect data and efficiently analyze these massive amounts of operational and service data, using technologies such as IoT, machine learning and predictive analytics. This will strain manufacturers’ existing organizations and IT infrastructures, necessitating investment in highly scalable cloud-based solutions to lay the foundation for a successful future.

    Manufacturers that embrace these changes will be the winners, while others will struggle to stay relevant. In fact, the ones who can successfully adapt to these paradigm shifts will be able to gain a significant competitive advantage over their competition.

    — Vivek Shah

  • 5 Ways DevSecOps Can Manage Software Supply Chains

    5 Ways DevSecOps Can Manage Software Supply Chains

    The unbridled use of open source components within the software supply chain is on a major uptick, according to new research. Even as this surge in open source dependencies fuels faster innovation, the study shows that it comes with high cybersecurity costs, as the number of breaches related to these components is similarly on the rise.

    However, the numbers also indicate there are some clear practices used by the best DevSecOps teams to minimize the risk while maximizing the speed and agility that third-party components offer.

    Sonatype and research partners from IT Revolution and Galois made a thorough analysis of download patterns, software component makeup and DevSecOps behaviors around open source components and third-party libraries for the “2019 State of the Software Supply Chain Report.” Their analysis found that the rate of open source component releases has picked up by 75% in the last two years and that download requests from teams using these components have risen 68% year over year.

    Most tellingly, the study showed that among modern applications today, 85% of the average code base is comprised of open source componentry. Not only are the majority of applications using open source components and libraries, but also they depend on them heavily.

    “The practice of assembling open source component releases into the form of an application screams of efficiency. Developers no longer need to code every line from scratch,” according to the report. “Developers can download component releases in seconds that deliver new capabilities, built by experts outside of their organizations who make their code freely available to others.”

    Perhaps not coincidentally, the study noted a parallel rise in breaches associated with open source component use. Last year 1 in 4 organizations suspected or verified they experienced a breach related to open source components in the last 12 months. That’s a slight improvement over last year’s stats, which had it pinned at 1 in 3 organizations. But since 2014, that rate of breaches has risen by 71%.

    The trouble is, many of the components developers download and integrate into their code are full of dangerous vulnerabilities. For example, just over half of all JavaScript package downloads contain known vulnerabilities, with 1 in 3 rated as high vulnerabilities. One in 10 of those flaws were rated as critical.

    The point the report hammered home is that not all components are created equally. There exists a certain class of well-run open source projects that release updates more frequently, update problematic vulnerabilities faster and remediate flaws more quickly. It is up to DevSecOps teams to systematically manage components, so they leverage more of these high-quality open source projects and try to avoid the riskier open source dependencies.

    “Management of software supply chains is not simply ensuring quality at velocity. Our supply chains are being attacked by adversaries in new and creative ways,” according to the report. It found that organizations that actively manage their supply chains are able to reduce the proportion of vulnerable components by 55% compared to those who do not.

    The report found several software supply chain practices contributed to this reduction of risk, with the following five standing out as the most impactful:

    Develop a governance program: Foundational to this is having some sort of open source governance or standards policies in place, according to the report, which noted that among the best DevSecOps organizations at managing risky components, nearly 3 in 4 have such policies in place.

    Have a process for evaluating and adding new components: As a part of that open source policy, the best teams have standardized processes for how developers add new open source components. This includes how these components are evaluated, approved, standardized and so on. The exemplary organizations are 11 times more likely to use this kind of process for new dependencies.

    Proactively remove problematic components: New vulnerabilities are discovered every day, so simply evaluating a dependency upon its first inclusion in an application can only take an organization so far. The best organizations also take the initiative to look for potential sources of open source vulnerabilities in existing code. That includes proactively seeking out and removing known vulnerable dependencies, as well as reducing the attack surface of the code by eliminating open source dependencies that aren’t being used. The best organizations are 9.3 times more likely to do so.

    Aim to always use the latest versions of components: It should go without saying that the latest version of any given component has the least vulnerabilities. The report showed that component releases that are 3 years or older have a 65% higher defect rate compared to newer components. Exemplary organizations strive to use the newest updates of all of their open source components and are 6.2 times more likely to do so than other organizations. That doesn’t happen accidentally—these teams are 10 times more likely to schedule update dependencies as part of the daily work of DevSecOps teams.

    Use Enforcement Automation: Just having a policy in place is not enough—organizations need to enforce the open source standards to reduce risk meaningfully. The study showed that DevOps practices combined with automated enforcement of policies increase developer adherence to standards by 150%. The exemplary teams with the lowest open source defect rates are 12 times more likely to have automated tools to track, manage and/or ensure policy compliance of open source dependencies.

    All of these best practices add up to less risk from components, as well as less pain for DevSecOps teams, who are three times less likely to consider the process of updating components as painful.

    — Ericka Chickowski

  • Google Launches Software Supply Chain Initiative

    Google Launches Software Supply Chain Initiative

    Maintaining the integrity of a software supply chain is an issue that has long bedeviled IT organizations. With the rise of microservices based on containers, however, this issue has become more acute. As a result, software supply chains are an issue that Google now plans to tackle.

    Google, along with JFrog, Red Hat, IBM, Black Duck, Twistlock, Aqua Security and CoreOS, is taking the lead on an open-source Grafeas initiative that aims to create a standard application programming interface (API) through which metadata about the software components that make up an IT environment can be more easily captured. The whole software supply chain issue has become even more challenging now that enterprise IT organizations regularly make use of open-source software within larger applications. There are now more dependencies on software modules that are being created and updated outside the IT organization, most of which are not prepared to keep track of the modules’ history.

    One of the first instances of Grafeas is going to manifest itself in the form of Kritis, a policy engine that Google has developed for the Kubernetes container orchestration engine. Because of its long history with Kubernetes, Stephen Elliott, product manager for developer platforms at Google, says Google tends to approach every issue these days through a container prism. But the expectation is that the Grafeas API will be more broadly applied to collect data about and enforce policies across a broad range of types of software components, he says.

    Elliott says that while there is no shortage of tools for managing software life cycle, each of those tools generate their own proprietary metadata. Grafeas promises to provide a consistent means to, for example, identity developers, determine when the code was checked in and built, what vulnerabilities have been detected, and what tests were passed or failed. Trying to manage those issues is at the heart of any approach to DevOps. A standard API would not only go a long way toward simplifying those issues, it also should also serve to make many of the tools DevOps teams rely on today more interoperable. That would also go a long way toward preventing IT organizations from finding themselves locked into a specific set of DevOps tools.

    Obviously, the launching of an initiative represents only the beginning of a process that should extend well into 2018. The number of IT vendors that have a vested interest in software supply chain issues exceeds that number that has signed on to the Grafeas initiative, and when this API issue is addressed by an industry standards body remains to be seen. Google is betting that as IT organizations become more familiar with microservices-based containers, there will be lot more support for addressing these issues now than anytime in the past. In the meantime, IT leaders should take some comfort in the fact that, at the very least, the IT vendor community is starting to better appreciate their software supply chain pain.

    — Mike Vizard

  • Sonatype Report Spotlights Software Supply Chain Issues

    Sonatype Report Spotlights Software Supply Chain Issues

    Most application developers today don’t write much raw code. Rather, applications developed today are created mostly by combing various modules and widgets to create a custom application. But currently there is little oversight being applied to the provenance of application components, especially when it comes to open-source software.

    The third annual State of the Software Supply Chain Report published by Sonatype, a provider of tools for managing software supply chains, finds that the amount of time it takes for open-source projects to address vulnerabilities is considerable. The report states that only 15.8 percent of open-source software projects actively fix vulnerabilities, resulting in an average mean time to remediation of 233 days. In effect, that gives cybercriminals the better part of a year to exploit a known vulnerability. Of course, that’s usually longer simply because most IT organizations are not especially efficient when it comes to regularly updating all the components that make up an application once it’s been deployed in production.

    Based on an analysis of more than 17,000 applications, the Sonatype report estimates downloads of Java components grew 68 percent (52 billion) year over year in 2016, while JavaScript downloads (59 billion) grew 262 percent.

    Matt Howard, chief marketing officer for Sonatype, says managing all the components that make up an application will only become more challenging as developers increasingly start to leverage Docker containers. The Sonatype report estimates there will be 12 billion downloads of Docker containers in 2017, a 100 percent increase over 2016.

    The good news is that more awareness of DevSecOps issues appears to be having an impact. The report finds the percent of Java components downloaded from the Sonatype Central Repository that contained known security vulnerabilities fell to 5.5 percent (1 in 18), down from 6.1 percent the year prior. Of course, that improvement needs to weigh against the 68 percent increase in downloads, which would suggest that the total number of components with known vulnerabilities finding their way into production applications has never been higher.

    By way of contrast, the report claims that applications built by teams employing automated governance tools reduced the percentage of defective components in their application by 63 percent. The report also says organizations that are actively managing the quality of open-source components flowing into production applications are realizing a 28 percent improvement in developer productivity, a 30 percent reduction in overall development costs and a 48 percent increase in application quality.

    The report makes clear that DevOps processes are not being extended far enough to the proverbial left. Instead of focusing on only on the application release cycle organizations need to apply structured processes to the components that are being aggregated together during the application development process. In fact, Howard notes that application development is moving away from being an art to more of a manufacturing process. As that shift continues to occur, it’s only a matter of time before a much greater emphasis gets placed on quality control all the way down that manufacturing line to not only limit liability but also generally improve the overall application experience.

    — Mike Vizard