Overview of the Breach

In late April 2019, Docker — the widely used container platform that lets engineering teams build, ship, and run applications in isolated environments — announced that an unauthorized party had gained access to one of its databases. Approximately 190,000 user accounts were affected. The exposed data included:

• Usernames
• Hashed passwords
• GitHub and Bitbucket OAuth access tokens (for a subset of affected users)

Docker disclosed the incident through its Support Center and via direct notification to potentially affected users, rather than through its main blog or social media channels — a communications decision that drew criticism from the security community.

What Was Compromised and Why It Matters

Usernames and Hashed Passwords

For users whose only exposed data was a username and a hashed password, the immediate risk was relatively limited — provided Docker used a strong hashing algorithm (such as bcrypt) with appropriate salting. Hashed passwords are not directly usable by an attacker; however, weak or commonly used passwords can still be cracked through dictionary attacks or rainbow table lookups. Users who reused their Docker password on other services faced a much higher risk of credential stuffing attacks on those accounts.

GitHub and Bitbucket Access Tokens — The Higher-Risk Exposure

The more serious concern involved OAuth access tokens for GitHub and Bitbucket. Docker Hub supports automated builds — a feature that links a Docker Hub repository to a source code repository on GitHub or Bitbucket so that a new container image is built automatically whenever code is pushed. These integrations rely on OAuth tokens that grant Docker Hub permission to read (and sometimes write) to the linked repositories.

According to reporting by Bleeping Computer, depending on the permissions granted to each token, a malicious actor in possession of these tokens could potentially:

• Read private source code repositories
• Modify repository contents, including injecting malicious code into build pipelines
• Trigger downstream supply-chain attacks affecting consumers of those Docker images

Docker stated that it revoked all known compromised access tokens promptly upon discovering the breach, which should have prevented active exploitation of those tokens after the revocation point. However, any access that occurred before revocation cannot be ruled out without a thorough audit of repository access logs.

Recommended Remediation Steps

Docker advised affected users to take the following actions. Even if you were not directly notified, these are good security hygiene practices for any Docker Hub account holder:

1. Change your Docker Hub password immediately. Choose a strong, unique password not used on any other service.
2. Check for password reuse. If you used the same password elsewhere, change it on those services as well. Consider using a password manager.
3. Reconnect GitHub and Bitbucket integrations. If your account used automated builds, revoke the existing OAuth connection and re-authorize it to generate a fresh token. Do this from the settings pages of both Docker Hub and the respective source code platform.
4. Audit your repository access logs. Review recent activity in your GitHub or Bitbucket repositories for any unexpected commits, branch modifications, or access from unfamiliar IPs.
5. Enable multi-factor authentication (MFA). Where supported, enable MFA on Docker Hub, GitHub, and Bitbucket to add a layer of protection beyond passwords alone.
6. Review OAuth token permissions. Apply the principle of least privilege when re-authorizing integrations — grant only the repository permissions that are actually required for the automated build workflow.

Broader Implications: Supply Chain Security

This incident is a clear example of why supply chain security matters in a containerized DevOps workflow. Automated build pipelines that connect source code repositories to image registries are a powerful productivity feature — but they also represent a trust boundary that attackers can exploit. If a token with write access to a repository is compromised, an attacker could inject malicious code that ends up packaged into a Docker image and pulled by downstream users, potentially at scale.

Teams that rely on Docker Hub automated builds or similar CI/CD integrations should treat OAuth tokens as high-value secrets, rotate them regularly, and monitor for anomalous repository activity as part of standard operations.

Context: Timing and Disclosure Approach

The breach was disclosed during a particularly active period for Docker. The company had just announced a partnership with Arm on April 24, 2019, aimed at simplifying deployment to cloud, edge, and IoT environments running Arm-based processors. DockerCon, the company’s annual container industry conference, also ran from April 29 to May 2. Docker’s choice to disclose the breach via its Support Center rather than its main communications channels was noted by observers as a way of limiting the incident’s visibility during a high-profile week for the company.

Regardless of the communications strategy, the incident highlights that even infrastructure vendors trusted to secure development pipelines are not immune to breaches — and that users of any platform bear responsibility for applying available security controls on their own accounts.

Further Learning: Docker Security

If this incident has prompted you to review your Docker security posture more broadly, consider exploring dedicated training on container security practices, including image scanning, secrets management, runtime security, and network policy configuration. DevOpsSchool offers a course titled Deep Dive into Docker Security that covers advanced Docker security topics for practitioners.

VMware updates NSX

VMware has updated its NSX network virtualization platform with two new releases, VMware NSX for vSphere 6.3 and VMware NSX-T 1.1. NSX for vSphere features enhanced security, extension of a unified virtual network to remote datacentres, and better support for vCloud Director. NSX-T adds support for VMware Photon Platform, an enterprise cloud-native infrastructure platform, expanded support for KVM distributions from Canonical and Red Hat, updated support for OpenStack Newton and Mikata, and access to a beta program in container networking and security for applications frameworks supporting the Container Network Interface (CNI) project. Both are available now.

Oracle updates cloud pricing

The Register reports that Oracle’s updated cloud licensing effectively doubles the price of the product on Amazon Web Services (AWS). It notes, “Oracle’s new cloud licensing policy says an AWS vCPU is now treated as a full core if hyperthreading is not enabled. A user renting two AWS vCPUS therefore needs to pay full freight for both, effectively doubling the number of Oracle licences required to run it inside AWS. And therefore doubling the cost as well. The new policy also says: ‘When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.’ That table says Xeon cores count as half a licence. Making the table inapplicable to the cloud again doubles the licence count required.” The Register says Oracle has not yet stated whether existing customers will be grandfathered, or how their agreements will be affected.

Solaris shifts to continuous delivery

In the wake of concerns that Oracle was killing its Solaris operating system after it removed Solaris 12 from its roadmap, the company has published a blog explaining its new strategy. It said that it is now using a continuous delivery model with more frequent updates to deliver patches and new features, rather than producing major releases. It has also extended the Oracle Solaris 11 and Oracle Solaris Cluster 4 Premier and Extended Support lifespans to January 2031 and January 2034, respectively. The company said, “By moving to a continuous delivery model based on Oracle Solaris 11, customers will have a seamless update experience to better fit their move to agile deployment models.”

Salesforce acquires Sequence

Salesforce has acquired 11 year old user experience design firm Sequence, whose customers include companies like Best Buy, Chipotle, and Apple. Sequence offers a range of services, including strategy, research, brand communication, design, development, and user interface design, prototyping, and usability testing. The Sequence blog announcing the acquisition says that team will “enhance Salesforce’s experience design capabilities, helping companies use the power of design to better connect with their customers in entirely new ways.” The deal closed on February 1, and financial terms were not disclosed.

Hewlett Packard Enterprise acquires Niara

HPE has announced that it has acquired user and entity behavioural analytics (UEBA) firm Niara. Niara’s technology will be used within HPE Aruba to enhance its ClearPass network security portfolio for wired and wireless networks. Niara’s software automates detection of attacks and anomalous behaviours, and integrates with the ClearPass network security platform so offending devices can be quickly dealt with. Terms of the deal were not announced.

Google announces additional Microsoft support on Cloud Platform

Google has announced that it is now providing pre-configured images for Microsoft SQL Server Enterprise and Windows Server Core on its Google Cloud Platform, as well as offering support for SQL Server AlwaysOn Availability Groups and persistent disk snapshots integrated with Volume Shadow Copy Service (VSS) on Windows Server. Customers can choose to launch Compute Engine VMs with SQL Server Enterprise Edition and Windows Server pre-installed and pay by the minute for the licenses, or bring their own SQL Server licenses.

2016: A Turning Point for DevOps and ALM

By the end of 2016, DevOps had moved well beyond the realm of early adopters and enthusiast engineers. Enterprise teams across industries — including government — were visibly accelerating their transitions to Agile development practices and DevOps delivery models. To capture what really changed that year, CollabNet interviewed a panel of leading application development industry analysts, asking them a single pointed question:

“What were the greatest successes made in 2016 in the software development industry, specifically for ALM and DevOps?”

Their answers highlight four distinct but interconnected themes: toolchain maturity, operational adoption, CI/CD pipeline growth, and container standardization.

What the Analysts Said

Toolchain Cohesion: From Chaos to Collaboration

“DevOps/ALM coming of age. Rather than being a ragtag collection of disparate tools chosen and used by individuals for their own ends, we are finally seeing tools coming through that enable full collaboration and control along the entire lifecycle, while still enabling a degree of individual choice as to the base tools being used.”

Clive Longbottom, Founder and Analyst, Quocirca

Longbottom’s observation reflects a long-standing tension in DevOps tooling: individual teams often selected their own preferred tools — version control, build systems, testing frameworks, deployment platforms — without any unifying layer. By 2016, a new generation of ALM and DevOps platforms began offering integrated lifecycle views while preserving team autonomy at the tooling level. This balance between standardization and flexibility became a defining characteristic of more mature DevOps environments.

Operational Adoption: From Theory to Practice

“I think the biggest success in the industry is simply getting companies to understand the significant value, and in some cases, the need for tools to assist in DevOps. DevOps and Agile are more than just the frameworks and ideas for faster application development but should be the model for the operational usage of them. That shift toward implementing operational usage and the tools needed for it was very important.”

Edwin Yuen, Analyst, ESG

Yuen identifies a critical maturity milestone: the transition from understanding DevOps as a conceptual framework to actually instrumenting it operationally. Many organizations in earlier years adopted Agile ceremonies or DevOps language without putting the supporting tooling and processes in place. 2016 saw a meaningful shift toward organizations investing in the concrete infrastructure — pipelines, automation, monitoring — needed to operationalize these practices at scale.

CI/CD Maturity: Automation Becomes the New Normal

“In application development and deployment, DevOps is now the new normal. Surveys are showing that virtually all enterprises practice Agile to some degree. The growing maturity of CI/CD products means that enterprises will be able to see higher levels of automation in the pipeline, faster time to value, higher levels of software quality, and increased IT productivity.”

Stephen Hendrick, AD Research

Hendrick’s framing — “DevOps is now the new normal” — encapsulates a significant cultural and organizational shift. Continuous Integration and Continuous Delivery (CI/CD) tooling had by 2016 matured to the point where enterprises could realistically automate large portions of their build, test, and release pipelines. The downstream benefits Hendrick cites — faster time to value, improved quality, and higher IT productivity — are outcomes that well-implemented CI/CD pipelines demonstrably support, though actual gains depend heavily on organizational context and implementation quality.

Container Standardization: The Open Container Initiative

“Containers have been with us for awhile now. The issue has been portability and standardization. The Open Container Initiative Docker PoC and Release Candidates opened the door for industry standards around container formats, which will support greater portability in the ALM/DevOps space.”

Altaz Valani, Senior Research Director, Application Development Practice, InfoTech Research Group

Container technology — particularly Docker — had been gaining momentum for several years before 2016, but fragmentation around formats and runtime behavior remained a real concern for enterprise adoption. The Open Container Initiative (OCI), launched in 2015 under the Linux Foundation, made meaningful progress in 2016 toward defining open, vendor-neutral standards for container image formats and runtimes. This standardization effort was important for organizations looking to avoid lock-in and to build portable, reproducible delivery pipelines across development, staging, and production environments.

Key Themes Emerging from 2016

• Toolchain integration over tool proliferation: The industry moved toward platforms that could provide a unified view of the software delivery lifecycle without forcing teams to abandon their preferred tools entirely.
• Operational maturity: DevOps stopped being just a cultural talking point and became something organizations were actively instrumenting with real pipelines, automation, and feedback loops.
• CI/CD as baseline expectation: Continuous integration and delivery shifted from a competitive differentiator to a baseline expectation in enterprise software delivery.
• Container standardization: Industry-wide standards work, particularly through the OCI, began reducing the portability and interoperability friction that had slowed enterprise container adoption.
• Broader organizational buy-in: DevOps and Agile practices expanded beyond development teams to influence operations, and in some cases, wider organizational structures including government agencies.

What This Meant for 2017 and Beyond

The analyst consensus from the close of 2016 pointed clearly toward a future where DevOps toolchain integration, automated pipelines, and container-based delivery would become table stakes rather than advanced practice. Organizations that had not yet begun their DevOps journeys faced increasing competitive pressure, while those already on the path were focused on scaling their practices and eliminating remaining manual bottlenecks.

The challenges heading into 2017 — cultural resistance, toolchain sprawl, skills gaps, and the difficulty of scaling Agile practices in large enterprises — would prove to be the defining conversations of the years that followed. These themes remain relevant for any team still navigating its DevOps transformation today.

Original analyst commentary sourced from CollabNet (blogs.collab.net), published January 2017. Analyst affiliations reflect their roles at the time of the original publication.

The Hiring Problem Nobody Wants to Admit

The DevOps talent shortage is one of the most-discussed problems in the industry. Companies at every scale complain they cannot find the right people. Recruiters blame a thin market. Candidates blame unrealistic job descriptions. Everyone agrees something is broken.

But here is the uncomfortable truth: we cannot even know whether a genuine talent shortage exists, because the hiring process itself is fundamentally broken—on both sides of the table. Recruiters do not know what they are actually looking for, and job seekers, responding rationally to those signals, present themselves in exactly the wrong way.

Adrian Cockcroft, formerly VP of Cloud Architecture at Netflix and later a partner at Battery Ventures, put it well when asked by large enterprises where Netflix found such great engineers. His answer: “We hired the same people you hired. We just got out of their way.” The talent exists. The environment and the selection process are what fail.

Andrew Clay Shafer, a well-known figure in the DevOps community, made a similar argument in a 2013 talk titled “There Is No Talent Shortage,” asserting that the people organisations need are already in front of them—they are simply looking for the wrong signals.

How Operations Engineering Changed

To understand why hiring is so confused, it helps to understand how Operations Engineering evolved. A decade ago, system administrators typically owned a specific subsystem: networking, storage, databases, or application servers. Roles were narrower and more specialised.

The rise of cloud platforms, on-demand infrastructure, and continuous delivery changed that entirely. Small ops teams—sometimes four to six people—now own the full production stack: infrastructure design, monitoring pipelines, deployment automation, configuration management, incident response, and security posture. Teams of five are doing work that once required tens of specialists.

This is genuinely new territory. There is no established academic curriculum for it. There is no certification that proves competence across the full breadth of the role. The skills required are still being discovered in real organisations, in production, under pressure.

What the “DevOps Engineer” Job Description Actually Looks Like

The HR response to this new reality has been to compress all of that complexity into a single job description. Here is a representative example drawn from a real LinkedIn posting (reproduced from the original source article):

Requirements: B.Sc. from a four-year university; at least 10 years of infrastructure development experience; 3+ years of AWS experience; 5–7 years of general DevOps/WS/DB/infrastructure experience; practical experience with EC2, Beanstalk, ELB, Route53, S3, CloudFront, SNS, SWF, SQS, RDS, DynamoDB, ElastiCache, IAM, and CloudFormation; familiarity with SOA principles; SDLC experience using Chef, Puppet, and CloudFormation; exposure to Chaos Monkey and Asgard; hands-on experience with monitoring, intrusion detection, and vulnerability assessment tools; general scripting wizardry.

Additional preferred skills: Familiarity with iTunes/App Store fundamentals; SQL and NoSQL experience; experience designing access control and authentication systems; strong verbal and written communication skills.

The person described in that job description does not exist—or if they do, they are already employed at a company that can match Google or Amazon compensation and offer them problems worth solving. Posting this description and waiting for that candidate to apply is not a hiring strategy. It is wishful thinking dressed up as a requirement.

Four Mistakes Breaking the DevOps Interview Process

Mistake 1: Job Descriptions Describe People Who Do Not Exist

The “DevOps Engineer” title has become a catch-all for CI/CD, configuration management, cloud architecture, automation, security, and infrastructure design. Organisations reason that if they can find one person who covers all of this, they save the cost of hiring several specialists. That reasoning is understandable. It is also wrong.

Modern Operations Engineering is a genuinely new profession. Developing deep competence across infrastructure design, observability, deployment pipelines, and security takes years—and the field itself is still evolving. Demanding that a candidate have achieved that depth with fewer than four years of the role even existing is incoherent.

The “years of experience” metric compounds the problem. The assumption that four years of experience outweighs two years is not supported by how people actually develop. Someone can be mediocre for five years while another person becomes genuinely skilled in two, depending on the environments they worked in, the problems they were given, and how intentionally they learned.

University degrees present a similar issue. Academic curricula move far slower than the technology industry. There is no university course that teaches you how to design a scalable monitoring pipeline, manage a Kubernetes cluster under load, or build a zero-downtime deployment strategy for a stateful service. These skills are learned in production, not in lectures.

Mistake 2: Interviewers Ask the Wrong Questions

Technical interviews for operations and DevOps roles frequently test memorisation of specifics: exact port numbers, configuration file syntax, command-line flags. These are the wrong things to test.

An experienced engineer who has not configured a GRE tunnel in Junos for two years will not remember the exact syntax—and that is fine. They know the concept, they know where to look, and they know how to validate whether it worked. Trivia-style questions eliminate strong generalist engineers while potentially passing candidates who have recently drilled specific technologies without understanding the underlying principles.

A better interview question: “Here is a system. Design the most secure pipeline for sending requests from an application server to a database. Walk me through your research process, the trade-offs you considered, and how you would validate the solution.” That question reveals how someone actually thinks—which is what you need to know.

Mistake 3: Candidates List Tools Instead of Demonstrating Capability

Consider a typical DevOps resume career summary:

System Administration: GNU/Linux (Debian, Ubuntu, Arch, CentOS, RHEL)
Virtualisation: LXC, KVM, OpenVZ, AWS
Configuration Management: Ansible, Chef (learning), Make
Languages: Python, Ruby (learning), Shell, C, C++, Java
Databases: OpenLDAP, MySQL, MariaDB
Version Control: Git, Subversion, Bazaar
Monitoring: Nagios, ntop, SSH, DHCP, DNS

Even assuming every item on that list represents genuine experience, this resume tells you almost nothing useful. It does not tell you whether this person can identify that a problem exists, let alone solve it. It does not tell you how they approach unfamiliar systems, how they handle failure under pressure, or what they have actually built.

Compare these two resume lines:

• Weak: “Experience with Nagios, Statsd, Graphite, Logstash, Elasticsearch, and Kibana.”
• Strong: “Researches and implements monitoring solutions for complex distributed systems. Built an observability pipeline at [Company] that reduced mean time to detection from 45 minutes to under 5 minutes.”

Or these:

• Weak: “Four years of experience with Ruby, Python, AWK, Shell, C, C++, Java, and JavaScript.”
• Strong: “Works primarily in Ruby and Python. Picks up new languages when the problem calls for it—recently learned Go to contribute to [open source project]. Example: [link to repository].”

The second version in each case gives an interviewer something concrete to follow up on. It signals intellectual honesty and genuine depth rather than keyword optimisation.

Mistake 4: Candidates Talk About the Wrong Things in Interviews

When a candidate is asked an open-ended architecture question, the temptation is to respond by listing the scale of systems managed or the variety of platforms encountered. Neither of those things answers the question.

The number of servers you have managed does not predict your ability to design a secure request pipeline. The range of IaaS platforms you have touched does not demonstrate that you can reason about trade-offs, document your thinking, or evaluate whether your solution actually worked.

What interviewers should be looking for—and what candidates should be demonstrating—is the process of problem-solving: how you identify the problem, how you research solutions, how you evaluate trade-offs, how you test your assumptions, and how you communicate what you found.

What Good DevOps Hiring Looks Like

For Recruiters and Hiring Managers

For Job Seekers

The Real Issue With “DevOps Engineer” as a Job Title

The term “DevOps Engineer” is itself part of the problem—not because the words are wrong, but because they have come to represent an impossible combination of skills rather than a genuine role. DevOps, as a concept, describes a culture of collaboration between development and operations teams, supported by automation and shared responsibility for production systems. It is not a job title. It is not a person.

Using it as a job title creates a feedback loop: recruiters post “DevOps Engineer” because they have heard the term and associate it with everything they need; candidates put “DevOps” on their resumes because they see it in job descriptions; and neither side is communicating anything precise. The term becomes a signal of buzzword compliance rather than genuine capability.

This does not mean the term should be banned from job descriptions. It means that when you write or read one, you should look past the label to the actual work being described—and evaluate candidates accordingly.

Conclusion

There may or may not be a DevOps talent shortage. We genuinely cannot tell, because the process for identifying and evaluating talent is too broken to produce a reliable signal. Recruiters are filtering for unicorns. Candidates are optimising for keyword matches. And real engineers with genuine problem-solving ability are falling through the gap between the two.

The fix is not complicated, but it does require both sides to be more honest about what matters. Organisations need to define the problems they need solved and evaluate candidates on their ability to think, learn, and deliver—not on whether their resume contains the right keywords. Candidates need to demonstrate the depth of their thinking, not the breadth of their tool exposure.

The talent is there. We are just not looking for it correctly.