devopsy.kinsta.cloud

Category: News

Cybersecurity Improvement Act of 2017: The Ghost of Congress Past
It seems like yesterday when when Representative Ed Royce proposed legislation titled the “Cyber Supply Chain Management and Transparency Act.” Almost three years have passed since Congressman Royce introduced his bill in November 2014 and helped educate the world about serious security vulnerabilities (such as Apache Struts and Heartbleed) lurking inside open-source components that are commonly used by anyone and everyone building modern software applications.

Broadly speaking, Royce’s bill would have required technology vendors selling software to the U.S. government to do the following:
1. Provide customers with a bill of materials documenting all open-source components utilized in the software application;
2. Demonstrate that the component versions utilized in the application have no known vulnerabilities (CVEs from NVD) for which less-vulnerable alternatives are available;
3. Provide a mechanism to promptly remediate new vulnerabilities when they are discovered.
Despite dying a quiet death, the Royce bill helped to pioneer an important conversation between government and industry leaders with respect to the age-old question of software liability.

This conversation continues to evolve—and just recently Sen. Mark Warner, a Democrat in Virginia, and Sen. Cory Gardner, a Republican from Colorado, introduced the “Internet of Things Cybersecurity Improvement Act of 2017“—an attempt to force companies selling IoT devices to federal agencies to adhere to new security standards.

Just like the Royce bill before it, the newly proposed legislation from Sen. Warner would require vendors selling IoT-connected devices to government customers to do three simple things:
1. Provide written certification that IoT devices do not contain hardware, software or firmware components with any known security vulnerabilities or defects listed in the NVD or similar databases.
2. Notify government customers of any new security vulnerabilities or defects subsequently discovered.
3. Provide a mechanism that allows for any future security vulnerability or defect in any part of the software or firmware to be patched or fixed in a timely and secure manner.
As Bruce Schneier observed more than a decade ago, there are no real consequences for having bad security or having low-quality software of any kind. Even worse, the market often rewards low quality. More precisely, it rewards additional features and timely release dates, even if they come at the expense of quality.

Although the Royce bill failed and the future of the Warner bill is yet to be determined, there is an increasingly steady breeze blowing from Washington, D.C., that is gently nudging the entire software industry toward a future in which vendors will no longer be immune to liability for damages due to known security vulnerabilities or defects.

About the Author / Matt Howard

A proven executive and entrepreneur with over 20 years experience developing high-growth software companies, Mr. Howard leads Sonatype‘s corporate marketing, strategic partnering, and demand-generation initiatives. Prior to Sonatype, he co-founded, developed and successfully sold two software companies. Earlier in his career, Howard led sales and marketing at USinternetworking (acquired by AT&T) and Groove Networks (acquired by Microsoft), where his teams distributed workgroup collaboration products to enterprise customers. Howard holds a Bachelor of Arts degree from The George Washington University and a Master of Arts from George Mason University.
August 17, 2017
CollabNet Merges with VersionOne for ALM Supremacy

Thanks to the rise of DevOps, there has been a lot of focus on various forms of application lifecycle management (ALM) spanning multiple application development methodologies. But as IT organizations become more comfortable with multiple methodologies, it turns out they are not replacing one with another as much as simply trying to figure out where to employ one over another. That, in turn, is driving some consolidation across the ALM category.

CollabNet this week announced it is merging with VersionOne, a provider of an ALM framework optimized for agile application development. While CollabNet has made some forays into the space, historically its primary focus has been on waterfall methodologies commonly used across larger enterprise IT organizations. CollabNet CEO Flint Brenton says the goal now is to combine the best of the ALM tools provided by both companies to enable IT organizations to leverage agile and waterfall methodologies as they best see fit. In fact, he says the biggest ALM issue facing organizations today is the need to balance developing applications faster and the inherent risks associated with potentially moving too quickly.

Robert Holler, formerly the CEO of VersionOne, will assume the post of chief strategy officer for the combined company. He says there’s very little overlap between the two company’s product portfolios, and the one thing that will distinguish CollabNet going forward is an open approach to ALM that enables organizations to employ whatever tools they prefer. Instead of forcing organizations to rip and replace those tools, Holler says ALM frameworks need to foster collaboration rather than trying to impose a closed ALM environment. That environment also needs to be deployable on-premises or in the cloud, depending on the requirements of the customer.

Holler notes that once any segment of the IT industry reaches a certain level of maturity, consolidation is all but inevitable. The opportunity CollabNet has is providing an ALM environment that makes it possible to automatically package and deploy applications that includes strong version-control mechanisms. Those capabilities will become even more critically important as IT organizations expand usage of microservices based on, for example Kubernetes, alongside traditional virtual machine deployments across the enterprise. Accomplishing that goal will require a common management layer capable of spanning both environments, he says.

The combined companies have more than 20,000 customers. That number may not collectively represent the lion’s share of the ALM market, but it does make CollabNet a serious contender against a host of rivals that are both a lot older and larger. CollabNet’s challenge now is convincing customers of competitive organizations to switch to an ALM platform that CollabNet contends is a whole lot more flexible.

In the meantime, it’ll be interesting to wait and see if the combination of CollabNet and VersionOne will drive any additional acquisitions at a time when IT organizations are becoming a lot less religious about what type of application development methodology gets employed by who and when.

— Mike Vizard

August 10, 2017
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

August 8, 2017
Loom Systems Extends Reach of AI into DevOps Realm

One of the things that tends to hold back adoption of DevOps are all the low-level events that need to be correlated by an engineer to generate anything that approaches actionable intelligence (AI). To eliminate that requirement, Loom Systems created a Loom AIops platform to automate many of the tasks that normally would need to be performed by a DevOps engineer.

Loom Systems has upgraded the Loom AIops platform by adding Distributed Entity Tracing, which makes it easier to analyze events across a range of interdependent applications and associated middleware. In addition, Loom has created Correlations View, which simplifies identifying how alerts being generated are related to one another.

Finally, the latest version of AIops adds support for the OpenStack cloud management framework, in addition to sporting a revamped set of dashboards that are easier to navigate.

Dror Mann, vice president of product for Loom Systems, says one of the reasons that DevOps is not widely implemented is that today it requires IT staffs to accumulate and correlate massive amounts of low-level event data to create anything approaching actionable intelligence. Loom AIops is designed to automate the low-level tasks relating to DevOps to enable the IT staff to focus more of their time and effort on fixing issues and reducing the time required to release and update applications.

Loom AIops, says Mann, accomplishes that goal by first streaming all the application log data into its platform, followed by all the log data generated by any dependencies that application might have. Loom AIops then applies machine learning algorithms in real time to identify the root cause of an issue. Armed with that information, it becomes a lot easier to reduce the mean time to resolution (MTR), which then provides the IT organization with the time needed to address more complex management challenges, he says.

Mann notes the single biggest challenge IT organizations encounter with DevOps is that it requires them to change their modus operandi. By automating many of the lower-level DevOps tasks, there’s more time available for IT organizations to think through the cultural changes required to successfully implemented integrated DevOps processes.

Most IT professionals will view the application of AI to IT operations with a combination of skepticism and trepidation. It will be difficult initially for many IT professionals to trust the analysis being generated by AI software. Once they do begin to trust that analysis, there naturally will be some concerns over to what degree an AI program can eliminate the need for a DevOps engineer altogether. But, Mann notes, there are many complex tasks that never get addressed because most DevOps engineers spend an inordinate amount of time and effort trying to correlate the right data.

At this juncture, usage of AI within the context of DevOps is now all but inevitable. The challenge now is not figuring out the line between where humans add higher orders of value compared to machines that are generally going to be limited to identifying patterns. The advantage a machine has it that once it learns something, it doesn’t forget it, take days off or switch jobs. However, being able to identify a pattern is not nearly the same as being able to apply reasoning to what the sum total of those patterns really means for the business.

— Mike Vizard

August 4, 2017
IBM: DevOps Challenges Require Managed Services
The DevOps complexity associated with determining which classes of application workloads are best-suited to run on certain platform types will push an increasing number of IT organizations to embrace managed services. That’s the premise put forth by IBM, which provides such a service.

Steve Robinson, general manager for IBM Cloud Platform Services, says it’s becoming less likely that internal IT operations teams will have the tools and expertise required to analyze and optimally deploy workloads. In fact, the number of platform choices have already exceeded the ability of most internal IT organizations to master. They include:
- Traditional virtual machines: The most widely deployed form a virtual machine software comes from VMware. But there’s already a lot of interest starting to emerge in so-called “micro VMs” that promise to reduce the memory footprint of VMs. However, rather than replacing traditional VMs, it’s probable micro VMs would be deployed alongside traditional VMs.
- Containers: Most containers today are deployed on top of virtual machines because of a lack of tools as well as security concerns. But as IT organizations become more adept at managing containers, many more of those containers will wind up running on bare-metal servers that will be able to attain much higher utilization rates by eliminating the need to deploy traditional virtual machines.
- Serverless Computing: Based on event-driven architecture, these platforms can be invoked natively as functions or simply be used to host containers. In either case, the need to provision servers, storage and networking resources is eliminated because IT infrastructure resources are made available on demand in real time.
- Graphical Processing Units (GPUs): As an alternative to Intel Xeon class processors, GPUs now are taking on many workloads involving machine-learning algorithms and big data because of their ability to process many of those workloads in parallel.
- Field Programmable Gate Arrays (FPGAs): Based on custom integrated circuits, FPGAs are being more widely employed within a variety of cloud services.
IT organizations today have the option to deploy any of these technologies on-premises or invoke them in the cloud. The issue most are contending with is a lack of advanced IT skills. In the absence of those skills, many IT organizations are in peril of falling behind their rivals. To overcome that issue, Robinson says it’s easier for many organizations to rely on third-party providers to manage their infrastructure while they concentrate their limited resources on application development.

Any increased reliance on managed services to gain the benefits of a more sophisticated approach to DevOps will vary widely by organization. Crafting DevOps process that span third-party organizations takes time and effort. There’s no way to analyze a workload and then automatically deploy it on the optimal platform without any human intervention. But as IT organizations continue to struggle with mastering DevOps processes, many may conclude it makes the most sense to rely on the expertise of a third-party service provider to manage a hybrid approach to DevOps. Regardless, the pressure to show results by increasing the amount of high-quality code being generated across the enterprise is mounting.

— Mike Vizard
August 4, 2017
NodeSource Gets to the Source of the Node.js Issue

There’s no shortage of variants of Node.js in the world, but NodeSource is making a DevOps-related case for why IT organizations should standardize on its runtime implementation.

NodeSource released version 2.3 of N|Solid, which adds support for event loop delay notifications that pinpoint precisely where an issue that needs to be addressed has occurred with an application, based on the Node.js variant of JavaScript.

Pravin Halady, product manager for NodeSource, says N|Solid uniquely provides a runtime implementation of Node.js that provides that capability. Coupled with tools to monitor applications based on N|Solid, additional visualization tools and configurable webhooks-based integration to create alerts that can be shared via collaboration platforms such as Slack, N|Solid is the only Node.js runtime specifically optimized for enterprise IT environments, Halady says.

He notes one of the thornier issues organizations that embrace Node.js face is that any long-term synchronous activity blocking the event loop can prevent other incoming requests from reaching the server. Before too long, the application hangs or simply crashes. By providing insights into when an event loop delay is occurring in real time, Halady says IT organizations don’t have to waste time trying to reproduce the problem. The result is a much faster time to resolution of Node.js application issues.

DevOps teams can find themselves dealing with those types of issues at a much higher level of frequency once developers employ Node.js. As adoption of the most widely employed variant of JavaScript increases, IT organizations are managing more applications than ever. In fact, a recent survey published by the Node.js Foundation finds that three out four respondents plan to increase their usage of Node.js over the next 12 months. The primary reasons cited for that additional usage are increased developer productivity (68 percent); improved developer satisfaction (65 percent); reduced development costs (58 percent); and increased application performance (50 percent). Nearly half the respondents (47 percent) working in enterprise IT organizations say they been using Node.js for more than three years. Over half the developers (58 percent), in contrast, report having more than 10 years of experience working with Node.js.

IT organizations generally have very little visibility into what’s occurring inside Node.js applications, which makes it difficult to apply DevOps processes. In fact, most DevOps processes in place today are wrapped around applications written in more mature languages such as Java. Developers employing JavaScript tend to not be as well-versed in the role programmers ideally play within the context of an integrated set of DevOps processes.

In the absence of those processes, having the tools needed to debug an application in real time becomes more important to an IT operations teams that needs to inform a developer about the root cause of a specific issue. Otherwise, the developer ends up running one test after another in the hopes of replicating the problem. Unfortunately, the probability of accomplishing that goal inside most organizations is often relatively low. Because of that issue alone, an event loop delay notification made in real time is likely to pay for itself in a matter of hours.

— Mike Vizard

August 1, 2017
Lack of Continuous Testing Mastery Slows DevOps Progress

Progress in achieving the maximum benefits to be gained from investing DevOps processes appears to be held in check by a failure to master the art of continuous testing. A new survey of 923 IT and testing professionals published this week by CA Technologies suggests that only 20 percent of the respondents could be classified as “leaders” when it comes to implementing continuous testing.

A full 93 percent of respondents identified testing automation as important, but only 1 in 5 respondents said they achieved a high level (80 percent or more) of test automation coverage. Seventy-five percent said continuous testing is important as well. Unfortunately, most of the respondents continue to rely on manual processes. In fact, respondents attributed continuous testing challenges to the lack of automation in almost every aspect of the testing process, including generation of test cases through test execution to critical activities such as fast, safe and efficient test data management.

Scott Edwards, senior director of product marketing for CA Technologies, says failure to automate continuous testing will only lead to an increased DevOps divide. Organizations that have automated DevOps processes not only release more code faster, the report find they enjoy advantages such as:

• 2.3 times more likely to have succeeded in left-shifting testing activity to developers;
• 2.6 times more likely to reduce defects by more than 50 percent;
• 2.4 times more confident in quality of output;
• 1.9 times more confident in speed of delivery; and
• 3.9 times more likely to be working in an organization exhibiting rapid revenue growth.

Edwards says those results indicate that organizations that are further down the DevOps process will enjoy a substantial competitive advantage at a time when organizations of all sizes are realizing how dependent they are on software to differentiate themselves. Organizations may be operating in a variety of vertical industries, but increasingly they are becoming software companies that happen to specialize in a specific area, says Edwards.

Making that shift requires IT organizations to move away from thinking about developing applications as an art to building what amounts to a software factory, he says. The factory approach not only eliminates silos in the DevOps process, it also should ideally allow developers to continuously test their own applications. Of course, the biggest issue with testing may very well be the simple fact that most developers build applications today using notebooks and workstations that don’t accurately reflect the complexity of the data center environments those applications will ultimately be deployed in. However, thanks to the rise of technologies such as service virtualization and cloud-based development environments, it has become easier to more closely mimic production environments.

The degree to which an absence of continuous testing impedes both the rate at which applications are deployed in a production environment will naturally vary by organization. But the one thing that is almost certain is that organizations that have mastered continuous testing are much more likely to deliver a quality application experience than those that don’t.

— Mike Vizard

July 21, 2017
Study: Half of Enterprises Have Achieved DevSecOps

The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.

In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.

In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.

Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.

DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.

It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.

Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.

The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.

The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.

— Mike Vizard

July 21, 2017
Pivotal Enlists Rackspace to Advance DevOps in Cloud Foundry Environments

In a sign of the level of complexity now associated with managing DevOps, Pivotal has partnered with Rackspace to create a managed services practice for its distribution of the Cloud Foundry platform-as-a-service (PaaS) environment.

Ian Andrews, vice president of product for Pivotal, says that at least half of the company’s customers have a least one instance of Pivotal Cloud Foundry (CF) that they would like to have managed by a third party. The reason for that is two-fold. For one, the Cloud Foundry PaaS can be complex for many IT organizations to deploy and manage on their own; Andrews notes that Pivotal releases updates to its distribution of the Cloud Foundry PaaS every 90 days. That’s a cadence the average internal IT organization is not prepared to keep pace with without help from an external services provider, he says.

Also, increased usage of microservices based on containers running on Cloud Foundry is driving organizations to shift allocation of their own internal resources away from managing underlying infrastructure. By relying on managed services providers such as Rackspace to manage both the PaaS and the underlying infrastructure, Andrews says more resources can be focused on managing the DevOps pipeline.

Pivotal opted to partner with Rackspace because Rackspace is capable to supporting instances of Cloud Foundry running on a public cloud, in a hosting center or on-premises, he says, adding that 60 percent of the Pivotal instances run on VMware vSphere platform, while the rest are distributed across multiple clouds and other on-premises environments. Pivotal is a sister company of VMware, operating under the umbrella of Dell Technologies.

Brannon Lacey, vice president and general manager for applications and platforms at Rackspace, says his company is embracing Pivotal as part of a larger push to deliver managed services above the infrastructure level. Previously, Lacey says, Rackspace managed e-commerce and content management applications, then acquired TriCore to add a portfolio of managed ERP application services. However, the company doesn’t have any plans to add more PaaS environments to its portfolio beyond the Cloud Foundry PaaS curated by Pivotal.

Historically, managed services have accounted for about a quarter of all IT spending. But as the number of deployment options available to IT organizations continue to expand, Lacey says Rackspace is expecting the number of companies that look beyond their internal IT organizations to manage that complexity will only increase.

As more managed services providers become part of the DevOps pipeline, it’s clear that many companies will soon need to consider how to create processes that extend well beyond their own organizations. That may prove to be a significant challenge because of the cadence of the update process is dictated by the external entities. Of course, IT organizations can dictate the pace of the upgrades. But the further an IT organization falls behind in terms of upgrades, the more expensive the managed service tends to become. In short, there’s no such thing as a proverbial DevOps easy button.

— Mike Vizard

July 21, 2017
Barracuda Networks Enhances API to Advance DevSecOps

Recognizing that DevOps teams deploying applications in the cloud need a more sophisticated approach to security, Barracuda Networks at the Microsoft Inspire 2017 conference unveiled an enhanced REST API for its Web Application Firewall (WAF), in addition to providing integration with the IT automation framework developed by Puppet Labs.

At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.

Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.

Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.

However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.

In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.

To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.

It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.

— Mike Vizard

July 18, 2017