staging-devopsy.kinsta.cloud

Tag: devsecops

  • DevSecOps Becomes a Higher Cloud-Native Priority

    DevSecOps Becomes a Higher Cloud-Native Priority

    At the Cloud Native Security Summit, Enterprise Strategy Group (ESG) today revealed the results of a survey of 600 senior IT leaders that finds organizations are looking at DevSecOps as a way to address the complexities of managing and securing cloud-native applications.

    According to the survey results, 43% of respondents said their biggest challenge with cloud-native applications is maintaining consistency across disparate infrastructures. As a result, the same number of respondents said DevSecOps automation as their highest cloud security priority.

    Commissioned by Capsule8, Obsidian and Signal Sciences, the survey also finds 90% of respondents are concerned about not having visibility into misconfigured cloud services, server workloads, network security or privileged accounts. Another 83% are worried about the misuse of privileged accounts by insiders.

    Two-thirds (66%) say IT is more complex than it was two years ago, with more than a third (35%) citing the need to manage multiple cybersecurity controls as a major source of that complexity.

    Doug Cahill, a senior analyst and group director at ESG, said it’s clear that as organizations embrace best DevOps practices to build and deploy cloud-native applications, those processes now are being extended to include security controls as part of the quality assurance process. Rather than bolting on security, Cahill said, more organizations are building cybersecurity controls into their software from the ground up.

    Capsule8 CEO John Viega noted much of that shift is being driven by necessity. When applications were deployed mainly in on-premises IT environments, it was easier to secure the environment by deploying appliances. Now organizations need to secure applications on infrastructure they don’t control as part of a shared responsibility model that often spans multiple cloud service providers. The cloud may be more agile and less expensive, but Viega noted it’s not uncommon for hundreds of cloud accounts to have been set up by individuals in the same organization, each with very different levels of cybersecurity expertise.

    Obsidian Security CTO Ben Johnson added the rate at which cloud-native applications are being deployed and updated is overwhelming the ability of cybersecurity teams to keep pace. In fact, many organizations are still underestimating the scope of the cloud-native cybersecurity challenge they face.

    Finally, Hala Al-Adwan, vice president of technology for Signal Sciences, observed as organizations embrace DevSecOps, cybersecurity professionals still will play a key role in terms of their consulting expertise. However, responsibility for implementing cybersecurity will continue to shift left toward DevOps teams. The challenge those teams will face is the need to replace legacy cybersecurity infrastructure designed for cybersecurity administrators with programmable tools that fit neatly within a continuous integration/continuous deployment environment, said Al-Adwan.

    It’s not clear precisely when a desire to embrace DevSecOps will result in more secure applications. In theory, cloud-native applications should be a lot more secure than legacy monolithic applications. However, the degree to which higher levels of security will motivate organizations to replace monolithic applications remains to be seen.

    In the meantime, cultural issues associated with embracing DevSecOps will abound. There are simply not enough cybersecurity professionals available to participate in every application development scrum session. The real issue now is finding a way to embed that knowledge into an application development process operating at industrial scale.

    — Mike Vizard

  • IoT Security Concerns

    IoT Security Concerns

    The Internet of Things (IoT) is being hailed as the next step in our technological development. It’s hard to argue with that. The abilities it provides are as captivating as they are numerous: smart cars and homes, automatized agriculture, advancements in medicine that help with after-stroke recovery and the list goes on.

    However, while the IoT is truly a huge topic nowadays, we must not let our fascination with it overcome us. It’s too easy to forget about security and privacy concerns when you hear about exoskeletons that can increase a person’s strength and dexterity–trust me, I know. But we can’t afford to forget about them.

    It does seem, though, in our pursuit of the interconnected device environment, the security of those devices was somewhat left behind. Let’s take a look at what the primary IoT cybersecurity hindrances are and what can be done to overcome them.

    When Security Struggles To Keep Pace

    One example of the quantity of devices outrunning their quality safety-wise is smart homes. They are very popular now, and according to the IDC forecast this trend is not going away:

    Data source: IDC Worldwide Quarterly Smart Home Device Tracker.

    While undeniably convenient, smart homes can pose a potential threat to their users. To do their job, they must collect information about those users. And the more interconnected the entire system gets, the more trouble can a single weak link cause.

    Take smart door locks, for example. Some of them come with facial recognition algorithms. That in itself is a pretty big privacy concern. Facial recognition can be used with an alarming accuracy to identify and track individuals. It can have various purposes, but very few of them (if any) are benevolent.

    To add to that, within the smart home system, a smart lock is going to be connected to other devices. Maybe it is safe from cyberattacks on its own, but is the smart thermostat safe? What about the smart water kettle? It only takes one vulnerability to get access to a lot of one’s private data.

    This risk can be somewhat mitigated by users taking certain precautions: installing AV software to protect their devices, updating the said devices regularly to prevent exploits, setting up a VPN on their routers to safeguard all of their internet traffic, etc. But how many users are actually going to go through with all this trouble?

    Physical Problems

    It should be noted that data breaches and cyberattacks are not the only threats the IoT faces. Some problems arise from poor design.

    For example, among other considerations presented in the June NIST publication, a non-descriptive appearance of an IoT device is mentioned. If it’s just a black box with no markings on it to indicate what software and hardware it runs on, updating it (as well as keeping track of its activities) becomes a very unpleasant chore. It is especially true if there are thousands of such devices located on the premises of a company.

    Alternatively, the support of a certain device may get discontinued well before the company plans to replace it. It is also possible the news of its discontinuation can be missed by the company, thus creating a possible vulnerability.

    Sheer Scale of the IoT Makes Threats Bigger, Too

    Another concern with the IoT is it’s so overwhelmingly difficult to maintain secure. If there is the need to install crucial updates on hundreds of millions of devices, the task becomes all but impossible.

    The hundreds of millions of devices example is not an exaggeration, either. Recently, several critical vulnerabilities were found in the VxWorks real-time operating system. Thankfully, this finding was not made by hackers but by a security firm. Some might think it should, therefore, be easy from now on for those vulnerabilities to be patched.

    Here comes the problem. There are 2 billion devices that run on VxWorks. Although not all of them can be affected by the vulnerabilities found, hundreds of millions still can. Moreover, there are difficulties in finding all the devices that need a patch, as it’s not obvious what devices even run on this RTOS.

    Many of the VxWorks devices are used in medicine. To update them, it is required they undergo the certification and testing processes, and that can take a long time. And before all the necessary testing is done, those devices remain vulnerable.

    Making the IoT Safer

    That’s why the approach to IoT device security must become more holistic than it is now. It is necessary for the IoT market itself to develop, as security and privacy issues were named one of the biggest problems hindering the implementation of smart devices.

    According to the recent Deloitte webcast, one of the biggest threats of the IoT today is security measures and systems are not incorporated into the core design of devices and networks. Another top risk is the lack of security awareness and training among engineers. Yet another one is the lack of proper incident response processes due to the wanting skill levels of security professionals.

    It’s obvious the IoT field can benefit immensely from the implementation of DevOps and, especially, DevSecOps. To ensure safety in the IoT, it is not enough to start worrying about it only after the fact, as an addition to other functions. On the contrary, it must become secure by design, and its safety must be a concern on all levels.

    — Dean Chester

  • GitLab Outlines Scope of DevOps Ambitions

    GitLab Outlines Scope of DevOps Ambitions

    At the GitLab Commit event in New York today, GitLab launched an ambitious effort to extend the scope of its DevOps platform to provide a view into the software development life cycle for not just developers but also designers, product managers and business leaders.

    Fresh off raising an additional $268 million in funding, GitLab now plans to create different ways to view a common pool of metadata and metrics generated by the GitLab DevOps platform.

    It may be a while before GitLab can deliver on that promise, but the core concept builds on the dashboards the company already has built for IT operations and cybersecurity teams. Rather than requiring each team participating in the software development process to acquire a separate platform, GitLab should be viewed as a DevOps platform delivered as a single application that can now be applied to everyone, said Mark Pundsack, vice president of product strategy for GitLab, in speaking with conference attendees.

    As part of that commitment, Pundsack noted GitLab is expanding its DevSecOps capabilities to include auto remediation. The scanning capabilities built into GitLab will be extended not only to detect issues based on the cybersecurity policies of an organization, but also, when allowed, automatically remediate routine issues, Pundsack said, adding GitLab also will automatically roll back applications if necessary. Once in place, GitLab will have pushed application cybersecurity much further left than anyone might have expected when DevSecOps was first broached as a concept, he said.

    At the conference, GitLab demonstrated a pipeline graph capability that will provide a foundation for many of these promised offerings. GitLab already can be employed to accomplish tasks such as code quality scanning, container scanning, dependency scanning and licensing dependencies.

    All these features are an extension of GitLab’s existing strategy that aims to rationalize the number of tools organizations need to stitch together to drive a set of best DevOps processes. However, other DevOps platform providers have similar ambitions.

    Thanks to its latest round of funding, GitLab—which also announced its plans to go public next year—is now valued at $2.75 billion. The company has not released any revenue results but does claim to support more than 100,000 organizations using its platform, including Ask Media Group, Charter Communications, Delta Air Lines, Goldman Sachs, Ticketmaster and Nvidia. GitLab also claims to have more than 4,800 active contributors to its open core platform. The company now has more than 800 employees in more than 55 countries across the globe, and there currently are 222 open GitLab jobs posted.

    It remains to be seen how much $268 million will enable GitLab to fend off rivals such as GitHub, which was acquired by Microsoft, and CloudBees, which has built a large DevOps community around the open source Jenkins continuous integration/continuous deployment (CI/CD) platform. Whatever the outcome of this arms race, the massive amount of funding pouring into the platforms soon should take DevOps platforms to places many might not have ever imagined possible.

    — Mike Vizard

  • Cloud Security: Self-Healing Infrastructure With Fugue

    Cloud Security: Self-Healing Infrastructure With Fugue

    Misconfiguration is the No. 1 cause for data breach in the cloud. Fugue helps to eliminate data breaches, as it fixes anything that gets drifted by providing baseline drift detection and automated remediation. Fugue is all about cloud security. It identifies security risks and compliance violations and ensures they’re never repeated.

    During this interview, Josh Stella, co-founder and CTO of Fugue, explained how his company offers developer-friendly tools that tell you if you are “breaking a rule and how to fix it,” providing visibility and control for all DevSecOps teams. With the self-healing cloud infrastructure, Fugue corrects misconfiguration and works on a whole configuration without having to write code or automation scripts.

    Check out the interview below, which also includes a demo of how the technology works by Stella himself.

    — Alan Shimel

  • From DevOps to DevSecOps: Owning Cloud Security

    From DevOps to DevSecOps: Owning Cloud Security

    The cloud is a complex environment, with different groups managing different cloud services and environments. The most basic division is between the cloud provider, who provides the core infrastructure, and the customer, who leverages services or builds their applications using resources leased from the provider. Within larger organizations, different cloud resources, data and applications may be owned by various lines of business, each with their own budget and development resources.

    From a security perspective, this sort of divided ownership of the cloud can create severe challenges in terms of end-to-end visibility, control and compliance. Of course, the cloud is a shared infrastructure, and when it comes to security events, there will likely always be some shared responsibility. But the lack of a centralized security strategy and inconsistent security policies and standards leading to potential grey areas of responsibility can create serious security gaps, and put critical data and other digital resources at risk.

    Cloud Provider vs. Customer Responsibility

    When respondents to a recent survey by IHS Markit were asked, “who is truly responsible when there is a vulnerability or security event in their cloud deployment?” the answer reflected a lack of understanding of the basic division of responsibility. Even in the best-case scenario, where it should be clear as to who is responsible for a security event (such as a vulnerability in the cloud platform), only about half of respondents were able to identify the root cause and responsibility.

    Complicating things further, there is yet another set of tools as to which responsibility should be clear. The list of security vendors available as add-ons through a cloud provider’s marketplace is exhaustive. The cloud providers themselves also offer a range of security solutions (built into their platforms as services). And many of the cloud management platforms, hypervisors, orchestration tools and other bits of cloud infrastructure have various levels of security available.

    However, the truth is adhering to the shared responsibility model, whenever the customer applies any configuration to these tools, they become his responsibility. Nonetheless, divisions of responsibilities are not always clear for different events.

    The best course of action is to identify and apply best practices to any resource and service consumed in the cloud. A root cause analysis (RCA) playbook should identify possible threats and plot actions where possible, and plot strategies for determining the root cause of an event. This includes identifying all key stakeholders, determining which investigation tools are available for threat analysis, establishing processes for orchestrating responses and resources between all parties and digitize and map those details to actual cloud technologies. Further, any response should be automated as much as possible.

    Security Responsibilities Within the Customer Domain

    Once the primary divisions of responsibility for a dealing with a security event is worked out between providers, vendors and customers–such as determining if a security breach is the result of a corrupted service or a misconfigured system–most cloud customers still have to address the divisions of responsibility within their own organization.

    The challenge is, when it comes to cloud security, too many companies don’t have a good handle on who is responsible for what. Part of the challenge is many organizations have taken an ad hoc approach to cloud development. As a result, today’s organizations, with an average of five different cloud environments in place and two or more in development, may be hamstrung by the challenge that each cloud instance might be owned by different lines of business.

    For many reasons, these groups may be reluctant to turn over the security of their individual cloud environment to the central security team. For example, speed is a critical component of DevOps efforts, so any security implementation that interferes with their primary objective of delivering applications is going to be a problem.

    Part of the reason is traditional IT security teams rarely know much about cloud environments, and the security tools they recommend often bottleneck development. However, handing over to the DevOps teams building out cloud applications and environments is problematic as they have little to no expertise when it comes to security.

    For example, one of the biggest challenges of many cloud-based security tools is the time and skill required to properly configure and manage them, let alone adjusting those configurations to eliminate false positives, or to ensure they don’t miss critical events or drop legitimate traffic. All that requires expertise most DevOps teams don’t have.

    Shifting from DevOps to DevSecOps

    Resolving this challenge can be as simple as adding a cybersecurity specialist to each of the various DevOps teams. Once integrated, DevSecOps can help navigate the fine line of the shared responsibility model to ensure both development and security requirements are met. They can negotiate between the customer/vendor/provider responsibility model, provide strategies for ensuring consistent security across and between cloud instances, and balance protection with performance.

    Part of that is achieved through the selection, deployment and management of tools designed to meet the twin challenges of speed and security. For example, many SaaS-based security solutions, such as web application firewalls, are self-scalable, allowing web applications to grow as needed without compromising protection. Choosing the right tool can also ensure it can be easily stitched into an application transaction with minimal effort. Some of them even have the advantage of having already included deployment, maintenance, scaling and fine-tuning functions.

    The proper application of automation plays an equally critical role in this process. Checking configurations and scanning objects for malware are time-consuming activities that can get pushed to the side when other issues arise. Automated cloud security solution selected and designed by the DevSecOps team can provide comprehensive configuration assessments, dynamically secure stored data, automatically scan for public cloud vulnerabilities, identify misconfigurations that put data at risk, scan files stored in the cloud and prevent the unauthorized downloading of sensitive information.

    Building a DevSecOps Team Requires Executive Support

    DevOps has become part of C-suite and board-level discussions, attesting to the growing critical value of web applications and digital transformation as part of the broader business strategy. However, if the frequency of breaches and the growing concerns of CISOs are any indication, executives aggressively pushing for cloud solutions often have a mistaken understanding of the nature of the security risks that cloud adoption and careless DevOps programs can introduce into their organization.

    Therefore, it is critical executive leadership is educated on the risks associated with expanding an organization’s digital footprint, and as a result, its new potential attack surface. Expanding DevOps to DevSecOps enables the integration of security into new cloud environments on day one. It can also ensure RCA cloud security playbooks are developed and followed, and help introduce and manage security solutions designed to protect critical digital resources without introducing unreasonable risks. Finally, it can provide a much-needed buffer against fines and penalties associated with regulatory requirement violations should their cloud deployment become a conduit for a severe system breach.

    — Lior Cohen

  • VMware Starts to Make DevSecOps Case

    VMware Starts to Make DevSecOps Case

    VMware, at the VMworld 2019 conference this week, strengthened its case for an application-centric approach to cybersecurity via updates to VMware AppDefense along with acquiring Intrinsic, a provider of a set of tools for securing serverless computing frameworks.

    VMware AppDefense layers a distributed service layered on top of the Platinum Edition of VMware Sphere platform that enables organizations to create a framework for whitelisting interactions between applications. Updates to the VMware AppDefense now enable organizations to run vulnerability reports across an entire application and virtual infrastructure stack along with support for integrity checks for the Windows operating system kernel.

    At the same time, VMware vSphere Platinum has now gained visibility and anomaly detection with automated reputation analysis for processes and network behaviors on a per-virtual machine basis. That capability is enabled by a collaboration with Kenna Security to feed risk-based data vulnerability metrics into the VMware AppDefense App Verification Cloud service.

    Additional capabilities include being able to initiate remediation actions based on the potential severity of a vulnerability, such as killing processes and network connections, and the ability to initiate remediation actions via the VMware NSX network virtualization overlay.

    At the same time, VMware also revealed that a future version of VMware AppDefense would also incorporate the technology that Intrinsic developed for securing serverless computing frameworks.

    Tom Corn, senior vice president and general manager for security products, said that move represents the first effort to extend the reach of AppDefense to include cloud-native computing environments. VMware AppDefense, coupled with an endpoint security service VMware is about to gain with the acquisition of Carbon Black, are at the core of its DevSecOps strategy, and rather than thinking in terms of endpoints at devices, the company will employ Carbon Black to secure applications as though they are the endpoint, he said.

    In some cases, Corn noted, that will require organizations to embed a lightweight agent within their applications. However, in many cases, platforms such as vSphere or Workspace ONE software will serve as the enforcement point because they already will have the Carbon Black agent software embedded. The Carbon Black agent also will be integrated with VMware Secure State, a real-time security and configuration monitoring service.

    The goal is to reduce the number of conflicting agent software strewn across an enterprise by various silos of cybersecurity technologies that don’t do much more than increase the operational cost of cybersecurity, said Corn. VMware is pursuing a more proactive approach focused on securing the entire application environment. That approach includes the web application firewall the company gained by acquiring Avi Networks earlier this year, he said.

    VMware already had a multiyear technology alliance with Carbon Black, so it has a good chance of achieving this goal soon once the acquisition is completed. In addition, as part of its DevSecOps strategy, AppDefense is already integrated with a variety of continuous integration/continuous deployment (CI/CD) platforms, Corn said.

    It may be a while before VMware fully delivers on that DevSecOps promise, but at the very least the DevSecOps dialogue in the enterprise is about to be elevated significantly.

    — Mike Vizard

  • Weighing the Cost of Improper DevSecOps

    Weighing the Cost of Improper DevSecOps

    Simply put, data breaches are terrible news for companies. And, the costs associated with such attacks continue to escalate. A recent IBM-sponsored report found an average price of 3.92 million per breach.

    Not adapting security automation and vulnerability scanning into development pipelines could have a drastic effect not only on cost but workload efficiency and team morale. With these sorts of headaches, it’s vital to consider the repercussions for not adopting secure (and lean) armaments and auditing procedures.

    Can organizations adopt DevSecOps beyond the buzzword it has become? In this article, we’ll uncover some startling evidence on the state of Kubernetes vulnerabilities and discuss what companies can do to rectify.

    Trends in Kubernetes and Istio Vulnerabilities

    It’s astounding how much in DevOps is left exploitable. Secrets are routinely unknowingly left in the open due to human error. These are the most common gateways for attackers. Plugging these gaps is the first, albeit obvious, step.

    There’s proof of an epidemic, too. A recent study conducted by Alcide ran a live production analysis of over 500 cloud-native environments across the globe. According to their findings, “89% of deployment scans show companies are not using Kubernetes’ secrets resources, with secrets wired in the open.”

    This means the majority of Kubernetes environments share susceptible to data breaches in some form. Among the 5,000 scans run, the Alcide report found secrets are commonly left open in a few areas, including:

    • Workloads that had to connect to cloud resources that exist outside the cluster
    • AWS access keys to connect to those resources
    • Tokens for workloads that require API access to external databases
    • Credentials for S3 buckets

    Gaps in Best Practices for Kubernetes and Istio

    Kubernetes brings many nuances to the table. It’s a sophisticated system, with a wide range of use cases and cloud-native experiences. These require extensive auditing and compliance checks to safeguard deployment.

    According to Gadi Naor, CTO and co-founder of Alcide, Kubernetes requires a good level of expertise. However, “there is a knowledge gap that DevOps doesn’t have,“ said Naor.

    Much of this gap lies in Kubernetes secrets handling and network policies. On top of Kubernetes, service meshes are a next evolutionary leap. Istio, an architecture layer for creating network policies is ten-fold more complex, according to Naor.

    On network policy creation, “75% of the scanned deployments use workloads, which mount high vulnerability host file systems; while none of the surveyed environments show segmentation implementation using Kubernetes’ network policies,” stated the Alcide study.

    These are compelling platforms, but best practices must meet the growing number of potential attack vectors.

    Why You Should Approach CI and CD Security Separately

    Many pundits now link continuous integration (CI) and continuous deployment (CD) together as if they’re synonymous. However, they are separate concepts. Securing them, in the same manner, could decrease overall efficiency.

    Scanning all resources created in the CI phase against security auditing could waste time and resources. For example, if you’re standing images for CVEs and only deploy 20% of those images, that is a lot of wasted exercises.

    Rather than scanning all environments in the CI phase, Naor believes you should focus on scanning 100% of images for CD. Therefore, security tooling is leaner, and anything deployed will be assuredly safe.

    Takeaways on the Cost of Poor DevSecOps

    Infrastructure components such as Kubernetes and Istio are powerful allies to the DevOps minded teams. These environments do come with their nuanced security concerns, which must be addressed. Otherwise, the data breach price tag is high.

    To intercept system frailties before the black hats do, you must consider the following:

    • Scan for the Obvious: Utilize automation to discover secrets, keys, tokens, left in public repositories.
    • Scan in a Lean Way: Maintain a lean security environment that retains your engineer’s attention.
    • CI vs CD: Recognize the security nuances between integration versus deployment.
    • Add Auditing Tooling Strategically: Adopt compliance and auditing tooling that doesn’t create friction with existing developer workflows.

    As Naor said, “Don’t ignore the obvious stuff.”

    — Bill Doerrfeld

  • DevOps Deeper Dive: VMware Transformed

    DevOps Deeper Dive: VMware Transformed

    At the VMworld 2019 conference this week, VMware in no uncertain teams made it clear it wants to become a major DevOps force.

    Following the acquisition of sister company Pivotal Software last week, VMware is moving to build out an application development framework for building and deploying cloud-native applications based on Kubernetes. That effort coincides with ongoing investments in its vRealize Suite of management tools, through which VMware is committed to automating IT operations across both on-premises IT environments and public cloud computing environments.

    To advance those twin goals, VMware this week launched a series of Tanzu management tools for managing any distribution of Kubernetes while at the same time launching VMware hybrid cloud platform, which combines everything—from vRealize automation tools to the monitoring tools from Wavefront by VMware—to create a central console through which all of IT can be managed.

    [su_box title=”The VMware DevOps Timeline”]

    • October 2015 – Dell Acquires VMware along with EMC
    • April 2017 – VMware acquires Wavefront monitoring service
    • August 2017 – VMware shifts public cloud strategy via Amazon Web Services (AWS) alliance; VMware and sister company Pivotal Software unveil Kubernetes distribution
    • November 2017 – VMware Launches VRealize Management Suite
    • February 2018 – VMware acquires CloudCoreo to gain cloud configuration tools
    • August 2018 – VMware acquires CloudHealth Technologies to gain governance tools; VMware launches AppDefense to provide a zero-trust framework
    • November 2018 – VMware acquires Heptio for Kubernetes expertise
    • December 2018 – Dell acquires all VMware outstanding shares
    • May 2019 – VMware Acquires Bitnami for application packaging tools
    • July 2019 – VMware Acquires Avi Networks to gain Web Application Firewall (WAF); VMware Acquires Bitfusion for machine learning algorithms and GPU virtualization software
    • August 2019 – VMware Acquires Pivotal Software; VMware Acquires Carbon Black; VMware Launches Tanzu Platform to manage Kubernetes; VMware Unveils Hybrid Cloud Platform

    [/su_box]

    After deciding to launch a series of services through which it manages instances of its software on public clouds such as Amazon Web Services (AWS) and local servers from sister company Dell EMC, VMware has been slowly expanding its reach into the realm of applications. The most significant element of that thrust to date has been its acquisition of Pivotal, a provider of the widely used Spring framework based on Java and a platform-as-a-service (PaaS) environment based on open source software from the Cloud Foundry Foundation (CFF).

    The CFF is in the process of migrating the application development environment created for Cloud Foundry to Kubernetes, a cloud-native container orchestration engine being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Both the CFF and the CNCF are arms of the Linux Foundation. The rise of Kubernetes has resulted in many organizations shifting their application development strategies to a platform capable of supporting multiple application development environments.

    Prior to announcing the deal to be acquired by VMware, Pivotal cut its revenue forecast for fiscal 2020 by $40 to $50 million.

    VMware DevOps
    VMware CEO Pat Gelsinger

    Pivotal Software spun out of VMware in 2013, so to a certain degree VMware’s move to acquire Pivotal represents something of a homecoming that last week was valued at $2.7 billion. Pivotal currently has about 350 customers, many of which are hosting a distribution of the Cloud Foundry PaaS on VMware platforms. VMware also tapped Pivotal to jointly develop a curated instance of Kubernetes, dubbed Pivotal Container Service (PKS), that is optimized for VMware platform. As part of that effort, VMware is also developing an instance of VMware vSphere that will run Kubernetes natively.

    At the VMworld 2019 conference, VMware CEO Pat Gelsinger made it clear VMware plans to leverage Kubernetes to bridge the historical divide between developers and IT operations teams. In fact, he told attendees Kubernetes was the most important technology to emerge since the virtual machine was created. As part of that effort, Gelsinger noted that the acquisition of Pivotal coupled with the recent acquisition of Bitnami, a provider of tools for packaging applications, means there are now more 5 million developers participating in the VMware ecosystem.

    VMware is clearly hoping the developer ecosystem will expand as VMware makes it easier to launch virtual machines on every major public cloud as well as on-premises IT environments. VMware has faced a major challenge over the last several years as DevOps teams have bypassed internal IT teams to deploy applications on cloud services based on alternative virtual machines by AWS or Microsoft. Thanks to the inherent portability of Kubernetes, VMware is hoping organizations will now deploy cloud-native applications on VMware platforms. It remains to be seen, however, to what degree DevOps teams will embrace VMware on public clouds versus continuing to employ those virtual machines.

    When it comes to cloud-native computing, VMware is clearly playing catchup. VMware has 250 PKS customers today, while rivals such as Red Hat (now an arm of IBM) have already redeployed their application development and deployment platforms on Kubernetes as an alternative to the Cloud Foundry PaaS. On the plus side, VMware now claims to be the third-largest contributor to Kubernetes, thanks in part to its acquisition of Heptio, a provider of Kubernetes tools.

    In the meantime, there’s no question VMware is at the forefront of developing tools for automating the management and securing of IT infrastructure running its virtual machine software. Less clear is to what degree VMware will be able to translate that success to also unify application development and IT operations across multiple platforms a truly meaningful DevOps way, rather than merely bundling a suite of disparate tools together at a discount.

    — Mike Vizard

  • Puppet Aims to Automate Vulnerability Remediation

    Puppet Aims to Automate Vulnerability Remediation

    Puppet today unveiled Puppet Remediate software, which makes it easier to prioritize and remediate software vulnerabilities automatically.

    Matt Waxman, vice president of products for Puppet, said Puppet Remediate builds on existing automation capabilities in the Puppet platform to make it easier for DevOps teams to focus on addressing vulnerabilities. Most existing approaches to addressing vulnerabilities rely on manual processes that often result in vulnerabilities not being addressed in an especially timely manner, he said.

    To accelerate that process, Puppet Remediate identifies vulnerabilities based on their potential severity and then gives DevOps teams the option to automatically remediate all known instances of that vulnerability, said Waxman. Puppet Remediate combines infrastructure data with vulnerability data gathered in real-time from Tenable, Qualys and Rapid7 to prioritize vulnerabilities.

    Puppet Remediate will not automatically remediate a vulnerability without the express approval of the DevOps team. That’s critical because in many instances the patch being applied still needs to be tested and vetted by the DevOps team, noted Waxman. Once approved, Puppet Remediate includes four pre-built tasks that allow DevOps teams to address more than 80% of the typical remediation workloads—importance because once a vulnerability is discovered, it’s not uncommon to find that same mistake has been made across many other software modules that have already been built and deployed.

    Deployed using Docker containers, Puppet Remediate relies on an agentless approach to vulnerability remediation that adds minimal overhead to either a Linux or Windows application environment, Waxman said. He added the goal is to make it easier for developers or cybersecurity teams to deploy Puppet Remediate on any platform.

    Waxman said the primary goal is to help organizations embrace best DevSecOps processes. In the absence of automation, the amount of time allocated to addressing vulnerabilities manually within existing applications often gets short shrift as developers race to meet deadlines for new applications. The irony, of course, is that each new application only serves to increase the number of potential vulnerabilities that need to be addressed. To restore order to vulnerability remediation process, Puppet is making the case for applying a proven IT automation framework to application security management.

    It may take a while for organizations to fully embrace automated application vulnerability remediation, but it would seem that, given the chronic shortage of cybersecurity professionals, adoption of these types of platforms is all but inevitable. There simply are not enough skilled cybersecurity professionals available to participate in every aspect of the application development and deployment process.

    At the very least, automated vulnerability remediation tools should inform developers of the mistakes being made most often. Over time, the number of instances of those vulnerabilities being discovered should decline as developers realize they are addressing the same issue repeatedly. Once that becomes obvious, hopefully that long-awaited teachable moment that eliminates that particular vulnerability from the application environment is finally at hand.

    — Mike Vizard

  • CircleCI Adds Security Orbs to CI/CD Platform

    CircleCI Adds Security Orbs to CI/CD Platform

    CircleCI has extended the reach of its automated package manager, known as orbs, to cybersecurity software that can be integrated into a pipeline constructed within the company’s namesake continuous integration/continuous deployment (CI/CD) platform.

    Mike Stahnke, vice president of engineering for CircleCI, said extending orbs into the realm of cybersecurity will make it much easier for organizations to embrace best DevSecOps processes.

    Designed to run on Amazon Web Services (AWS) and Google Cloud, the first set of orbs are being created by seven third-party cybersecurity vendors, including Alcide.io, NeuVector, Snyk, WhiteSource, Aqua Security, Anchore, Contrast Security, Probely and Twistlock, which is now part of Palo Alto Networks.

    CircleCI has been making use of orb package managers to make it easier to integrate a wide variety of functions within a CI/CD pipeline. Thus far, approximately 900 orbs have been developed for the CircleCI platform. Stahnke said the goal is to give DevOps teams the option of employing orbs instead of having to manually implement tasks such as secrets management, vulnerability scanning or policy enforcement into DevOps workflows.

    Stahnke said CircleCI doesn’t envision every element of a pipeline will become an orb; there will be instances where DevOps teams will want to exercise more granular control over some aspect of the pipeline. There are, however, going to be many situations in which DevOps teams won’t want to integrate the same functions manually over and over again.

    CircleCI expects orbs will prove especially useful in advancing the adoption of best DevSecOps processes because many of the controls that need to be implemented are the same across multiple pipelines, said Stahnke. By making it easier to incorporate cybersecurity software within a pipeline, DevOps teams will not have to sacrifice speed and agility to ensure security.

    CircleCI orbs

    Most organizations today are just starting down the DevSecOps path. Adoption of DevOps processes in many cases has been uneven at best. Trying to incorporate cybersecurity teams within those processes to ensure higher levels of security is the next great challenge. However, given the chronic shortage of cybersecurity professionals, cybersecurity functions within a DevOps pipeline somehow must be included automatically. In most cases, cybersecurity teams will continue to define policies and controls that increasingly are implemented by developers. Cybersecurity teams, however, still will need to validate that those controls have been implemented and tested before an application gets deployed in a production environment. Cybersecurity teams will then make developers aware of any vulnerabilities they’ve discovered and teams can decide to address them at whatever next stage of the development process they deem appropriate.

    Of course, DevSecOps also means cybersecurity teams will have to learn to trust developers. Historically, that’s been problematic because many cybersecurity professionals have tended to view developers as the primary source of the cybersecurity problem. Nevertheless, the more vulnerabilities that get addressed before an application is deployed in a production environment, the better off everyone involved in building, deploying and securing that application will be.

    — Mike Vizard