What Is GitHub Super Linter?

GitHub Super Linter is a ready-made GitHub Actions workflow that automatically lints code whenever a pull request is opened against your repository. Its primary goal is straightforward: prevent broken or poorly formatted code from ever reaching your main branch by catching issues early in the review cycle.

Rather than requiring teams to individually configure a separate linter for each programming language in their codebase, Super Linter bundles multiple open-source linters into a single Docker container that GitHub Actions invokes on demand. This dramatically reduces the setup overhead for enforcing code quality standards across polyglot repositories.

How Super Linter Works

When a developer opens a pull request, Super Linter triggers automatically via GitHub Actions. It inspects the changed files, runs the appropriate linter or linters for each language detected, and reports results back through the GitHub Status API. The pull request will show a clear pass or fail status, and any errors are surfaced with details about their location and nature.

The workflow is iterative by design:

• A developer opens a pull request.
• Super Linter runs and reports any detected issues.
• The developer fixes the reported issues and updates the pull request.
• Super Linter runs again; if no further issues are found, the pull request is clear to merge.

Language Support

Super Linter supports a broad range of programming languages and file formats. At launch, the list included — but was not limited to — JavaScript, TypeScript, Python 3, Perl, and Go (Golang). Because the supported linters are packaged inside a Docker container, adding or updating language support is managed at the container level rather than requiring individual repository changes.

Check the official Super Linter repository on GitHub for the current, authoritative list of supported languages and linters, as this has expanded significantly since the initial release.

Configuration and Customization

Super Linter is designed to work out of the box with sensible defaults, but it exposes several customization mechanisms for teams that need to align it with their own coding standards.

Custom Rule Files

You can override the default linter configuration by placing your own rule files in the .github/linters/ directory of your repository. Super Linter will pick these up automatically. If no custom rules are provided, it falls back to its built-in defaults.

Environment Variables

Super Linter exposes a range of environment variables that control its behavior. Some notable examples:

• VALIDATE_ALL_CODEBASE: When set to true, Super Linter lints every file in the repository rather than only files changed in the current pull request. This is useful for an initial baseline scan of a legacy codebase.
• Per-language flags: Individual environment variables allow you to enable or disable linting for specific languages, giving teams granular control over which checks are enforced.
• Rule suppression: Specific linters or rules can be disabled to intentionally ignore certain warnings or errors that are not applicable to your project.

Impact on Pull Request Workflows

By automating linting at the pull request stage, Super Linter shifts code quality enforcement left in the development cycle. Reviewers spend less time pointing out formatting or style violations manually, freeing them to focus on logic, architecture, and correctness. According to GitHub, this is intended to establish consistent coding practices across languages and make collaboration on pull requests more efficient.

How It Compares to GitLab Code Quality

GitLab offers a comparable feature called Code Quality, which uses CodeClimate engines to perform automated code review before merge. At the time of Super Linter’s release, GitLab’s Code Quality supported fewer languages than Super Linter, though GitLab indicated plans to expand language coverage. The two solutions reflect different integration philosophies: Super Linter is tightly coupled to GitHub Actions and linter tooling, while GitLab Code Quality leverages the CodeClimate ecosystem.

Super Linter in the Context of Cloud-Based Development

Super Linter’s arrival coincided with a broader trend of moving developer tooling into the cloud. Around the same time, GitHub introduced GitHub Codespaces, which provides a fully configured, browser-accessible Visual Studio Code environment hosted within GitHub itself. Together, these tools represent GitHub’s push toward a fully cloud-native development experience — where code is written, linted, reviewed, and merged without ever leaving the platform.

Getting Started

To add Super Linter to an existing repository, create a GitHub Actions workflow file (for example, .github/workflows/linter.yml) that references the Super Linter action. The official repository provides a minimal starter workflow. From there, you can layer in custom rule files and environment variable overrides as your team’s needs evolve.

For full setup instructions, supported linter versions, and the latest configuration options, refer to the Super Linter GitHub repository.

From Monoliths to Thousands of Daily Deployments

Not long ago, enterprise software teams considered a major release every 12 to 18 months a reasonable cadence. Today that benchmark looks prehistoric. Traditional B2B software vendors now ship code every quarter, with incremental updates in between. B2B SaaS vendors move faster still, often releasing multiple times per week.

In the direct-to-consumer sector, the pace is genuinely staggering. Large retailers operating API-driven back ends — with thousands of applications calling tens of thousands of APIs — routinely execute thousands of releases per day, with individual releases rolling out across hundreds of servers simultaneously. This is not the exception; it is the new competitive baseline.

Why Automation Is No Longer Optional

At that release velocity, manual processes simply cannot keep pace. Security testing, quality assurance, and compliance checks must all be embedded into automated pipelines. No human team can review, test, and sign off on thousands of changes per day by hand without either becoming a bottleneck or missing critical defects.

Automation requires investment — in tooling, in platform engineering, and in the people who build and maintain pipelines. Justifying that investment to leadership is easier when you can tie release speed directly to measurable business outcomes: conversion rates, average order value, time-to-market for new features, and mean time to recovery (MTTR) after incidents.

Rework Is the Hidden Productivity Killer

One of the greatest threats to a high release cadence is rework — going back to fix code that was written incorrectly, failed a security scan, or did not meet requirements. Rework consumes engineering hours, delays releases, and demoralizes teams. The only sustainable way to maintain velocity is to get things right the first time, which requires shifting quality and security checks as early in the software development life cycle (SDLC) as possible.

Practical steps to reduce rework include:

• Code reviews: Use the knowledge of senior engineers to catch problems before code is merged. Peer review is one of the highest-return quality practices available.
• Developer-owned testing tools: Equip developers with linters, static analysis tools, and unit test frameworks so they can identify and fix common errors — including security issues — without waiting for a separate QA team.
• Automated test suites: Build a repeatable, version-controlled suite of tests that runs on every commit. Automated tests never tire, never skip steps, and execute in a fraction of the time required for manual testing.
• Secure coding education: Train developers to recognize security risks at the design and implementation stage — before vulnerable code is ever written. Shift-left security dramatically reduces the cost of remediation.

Open Source Is Accelerating Development — and Risk

A significant reason modern teams can ship so quickly is open source software (OSS). Reusing battle-tested libraries and frameworks — available on platforms like GitHub under permissive licenses — means developers spend more time assembling components than writing code from scratch.

The scale of OSS adoption is enormous. Industry analysis consistently shows that the vast majority of commercial applications contain open source components, and the proportion has grown significantly over the past decade. Some estimates suggest developers may author less than 10% of the code in a typical new application, with the rest coming from third-party libraries and frameworks.

This acceleration comes with a trade-off: open source components introduce third-party vulnerabilities that teams must actively track and remediate. Software composition analysis (SCA) tools that scan dependencies and alert on known CVEs are now a standard part of a mature DevSecOps pipeline.

What High-Performing DevOps Teams Actually Achieve

Research from DORA (DevOps Research and Assessment), published in its annual Accelerate: State of DevOps report, has consistently documented the performance gap between elite and low-performing software organizations. High performers demonstrate measurably better outcomes across every key metric, including:

• Deployment frequency: Deploying on demand, multiple times per day, versus once per month or less for low performers.
• Lead time for changes: From code commit to production in hours, versus weeks or months.
• Change failure rate: A small percentage of deployments cause incidents, compared to significantly higher rates for low performers.
• Mean time to recovery (MTTR): Restoring service in under an hour after an incident, versus days or weeks.

These are not incremental improvements — they are order-of-magnitude differences driven by automation, good engineering practices, and a culture of continuous improvement.

Speed Without Security Is a Liability

The same internet-facing APIs and microservices that enable rapid delivery also expand the attack surface. Business logic is increasingly exposed directly to end users and third-party integrators, which means vulnerabilities in production have real and immediate consequences — data breaches, compliance failures, and reputational damage.

Security cannot be bolted on at the end of a fast-moving pipeline. It must be integrated throughout: in code review, in automated static and dynamic analysis, in dependency scanning, and in runtime monitoring. This is the core promise of DevSecOps — making security a shared, continuous responsibility rather than a gate at the end of the release process.

The Bottom Line for DevOps Teams

The shift from annual releases to continuous delivery is not a trend that will reverse. The organizations winning in competitive markets are those that have built the automation, culture, and engineering discipline to innovate rapidly without sacrificing stability or security. For DevOps practitioners, the imperative is clear: invest in the pipelines, tooling, and practices that let your team move fast confidently — or risk being outpaced by those who have.

In follow-on coverage, we will look specifically at application security strategies — including SAST, DAST, SCA, and secrets management — and how to integrate them into a high-velocity CI/CD pipeline without becoming a bottleneck.

This article covers five widely adopted open source projects that extend Kubernetes in key areas relevant to developers, platform engineers, and SREs alike.

Why Kubernetes Needs a Supporting Ecosystem

Kubernetes deliberately focuses on core container orchestration concerns: scheduling, replication, networking, storage, and failover. It intentionally avoids baking in opinionated solutions for every operational problem. Cloud-native architectures—built on microservices, distributed systems, and dynamic infrastructure—introduce challenges that go well beyond what core Kubernetes addresses out of the box. The projects below fill those gaps.

1. Prometheus

Prometheus is an open source systems monitoring and alerting toolkit originally built at SoundCloud. It was the second project to join the Cloud Native Computing Foundation (CNCF), right after Kubernetes itself—a signal of how central observability is to cloud-native operations.

Prometheus is built around a multi-dimensional, time-series data model. It scrapes metrics from instrumented targets at defined intervals, stores the data locally, and exposes a powerful query language called PromQL for analysis and alerting. Key characteristics include:

• Pull-based metrics collection: Prometheus scrapes HTTP endpoints exposed by your services, making it well-suited for dynamic environments where instances come and go.
• Service discovery: Native integrations with Kubernetes service discovery mean Prometheus can automatically find and monitor new pods and services without manual configuration changes.
• Alertmanager integration: Alerts defined via PromQL rules are routed through Alertmanager, which handles deduplication, grouping, and notification routing to tools like PagerDuty, Slack, or email.
• Microservice-aware monitoring: Unlike traditional monitoring tools designed for monolithic applications, Prometheus handles the dynamic, ephemeral nature of containerized microservices naturally.

Prometheus is often deployed alongside complementary observability tools. Jaeger provides distributed tracing for troubleshooting microservice interactions. Istio, a popular service mesh, aggregates telemetry data, manages traffic flow, and enforces policies across microservices. Together, these tools form a solid observability stack for Kubernetes environments.

2. Operator Framework

Kubernetes provides excellent general-purpose abstractions for deploying and scaling applications, but managing stateful, complex applications—like database clusters, message brokers, or certificate managers—requires domain-specific operational knowledge. Kubernetes Operators encode that knowledge in software.

An Operator extends the Kubernetes API with custom resources and a controller that watches those resources and takes action to reconcile desired state with actual state. In practical terms, an Operator for a database cluster might:

• Spin up cluster members in the correct startup order.
• Handle rolling upgrades without data loss.
• Automatically trigger and manage backups on a schedule.
• Detect and recover from node failures.
• Scale the cluster up or down in response to load.

This is sometimes described in terms of Day 1 operations (initial deployment and configuration) and Day 2 operations (ongoing maintenance, upgrades, and recovery). Kubernetes handles much of Day 1; Operators make Day 2 automation practical.

The Operator Framework is the toolset that makes building and packaging Operators practical. It includes the Operator SDK (for building Operators in Go, Ansible, or Helm), Operator Lifecycle Manager (OLM) for installing and managing Operators in a cluster, and the OperatorHub.io registry for discovering and sharing community and vendor-built Operators.

Operators are a direct software embodiment of Site Reliability Engineering (SRE) principles: automate toil so that operational tasks don’t need to be performed manually every time they arise.

3. Knative

Knative brings serverless capabilities to Kubernetes. Rather than locking workloads into a cloud provider’s proprietary Functions-as-a-Service offering, Knative lets you run serverless-style workloads on any Kubernetes cluster—on-premises or in any cloud.

Knative is organized around two main components:

• Knative Serving: Manages the deployment and scaling of containerized applications, including scale-to-zero when there is no traffic. It handles request routing, revision tracking (allowing traffic splits between versions), and automatic TLS termination.
• Knative Eventing: Provides an event-driven infrastructure layer. It enables applications to consume and produce events using a standard, broker-based model, decoupling event producers from consumers in a way that is compatible with the CloudEvents specification.

The key benefits Knative offers over native provider serverless services are portability and flexibility. Because it runs on standard Kubernetes, applications are not tied to a single cloud provider’s infrastructure. Knative also supports workloads that are more complex than simple event-triggered functions—including long-running microservices and containerized workloads that use stateful backing services deployed via Operators.

For organizations focused on developer velocity, Knative reduces the operational surface developers need to manage: networking configuration, autoscaling logic, and revision management are handled by the platform rather than the application code.

Putting It Together: The Modular Kubernetes Platform

None of these projects is mandatory, and none is mutually exclusive with the others. The modular nature of the Kubernetes ecosystem means teams can assemble a platform tailored to their workloads and organizational maturity:

• Use Prometheus (with Alertmanager and Grafana) for metrics-based observability.
• Add Jaeger or a similar tool for distributed tracing.
• Deploy an Istio or similar service mesh if you need advanced traffic management and telemetry across microservices.
• Use the Operator Framework to manage stateful workloads and automate Day 2 operations.
• Adopt Knative to enable serverless and event-driven application patterns without cloud provider lock-in.

The original article references two additional projects not detailed above (the source lists five total but the available text covers three in depth). The original source for this content is the Enterprisers Project; refer to the original article for the full list.

Further Reading

• Prometheus documentation
• Operator Framework
• OperatorHub.io — discover and share Kubernetes Operators
• Knative documentation
• Jaeger distributed tracing
• Istio service mesh

Azure Quantum Opens to Select Developers

At its Build 2020 developer conference, Microsoft announced a limited preview of Azure Quantum, making its cloud-based quantum computing platform available to select developers and enterprises. The company positioned the release as the product of nearly two decades of internal quantum research, embedded across every layer of the Azure Quantum stack.

The limited preview gives participants access to an open ecosystem that spans quantum software, hardware, and solutions — sourced from both Microsoft and a set of launch partners.

Partner Ecosystem and Hardware Access

Azure Quantum launched with hardware and software contributions from four key partners:

• 1QBit — quantum software and optimization solutions
• Honeywell — trapped-ion quantum hardware
• IonQ — trapped-ion quantum processors
• QCI (Quantum Computing Inc.) — quantum-ready software solutions

By aggregating multiple hardware backends under a single cloud platform, Microsoft aims to give developers the flexibility to target different quantum architectures without having to manage separate vendor relationships or toolchains.

Quantum-Inspired Solutions for Classical Hardware

Alongside access to actual quantum processors, Azure Quantum also offers what Microsoft calls quantum-inspired solutions — optimization algorithms derived from quantum computing research that run on classical hardware. These pre-built solutions are designed to tackle complex optimization problems in logistics, finance, and scheduling without requiring a physical quantum machine, making them immediately practical for enterprise workloads.

The Road to a Scalable Quantum Computer

At the time of the announcement, Microsoft had not yet publicly demonstrated a general-purpose quantum supercomputer. Microsoft’s longer-term research program is focused on topological qubits — an approach the company believes will produce more stable and scalable quantum processors compared to competing qubit technologies. Researchers were described as actively developing the software infrastructure needed to support a future scalable quantum machine.

Microsoft expressed confidence that a scalable quantum machine could be achievable within a five-year horizon from the time of the announcement, though no firm timeline or performance milestones were committed to publicly.

Why Qubits Matter: A Quick Primer

Classical computers store and process information as bits — binary values that are either 0 or 1 at any given moment. This binary constraint limits throughput when processing combinatorially large problem spaces.

Quantum computers instead use qubits, which exploit quantum mechanical properties — specifically superposition and entanglement — to represent and process 0 and 1 simultaneously. This allows a quantum processor to evaluate many possible solutions in parallel, offering a theoretical advantage for specific problem classes such as:

• Cryptography and security
• Drug discovery and molecular simulation
• Climate modeling and clean energy research
• Materials design
• Large-scale optimization problems

It is important to note that quantum computers are not universally faster than classical machines — they offer advantages only for specific problem types where quantum algorithms apply.

Competitive Context

Microsoft’s announcement came in the context of a rapidly accelerating quantum computing race. Google had previously claimed to have demonstrated quantum supremacy with its Sycamore processor, reportedly completing a specific calculation in approximately 200 seconds that Google estimated would take classical supercomputers thousands of years — a claim that was subsequently disputed by IBM and others regarding the classical comparison baseline. IBM, Google, and Amazon (via Amazon Braket) were also offering quantum cloud services at the time, making Azure Quantum a direct competitive entry into an already active market.

What This Means for DevOps and Cloud Engineers

For DevOps practitioners and cloud engineers, the Azure Quantum preview represented a low-friction entry point into quantum development. Key practical takeaways from the announcement include:

• Unified access: Multiple quantum hardware backends accessible through the familiar Azure portal and SDK.
• Classical bridge: Quantum-inspired optimization tools that work today on classical infrastructure, without waiting for fault-tolerant quantum hardware.
• Open ecosystem: Microsoft’s stated goal of an open platform means developers are not locked into a single hardware vendor.
• Q# language: Microsoft’s domain-specific language for quantum programming, Q#, is the primary development interface for Azure Quantum workloads.

As quantum computing matures from research curiosity to cloud service, familiarity with hybrid classical-quantum workflows is increasingly relevant for engineers working in high-performance computing, AI infrastructure, and scientific computing domains.

Combining IAM with Docker and Kubernetes for Competitive Advantage

As enterprises accelerate digital transformation and shift more workloads to the cloud, the need to deliver secure, scalable identity and access management (IAM) faster has never been more urgent. One effective strategy is adopting a multi-cloud DevOps deployment model that leverages containerization and orchestration technologies — specifically Docker and Kubernetes. This approach enables organizations to speed time to market, scale dynamically for peak demand, and reduce operational overhead.

Why Traditional IAM Struggles to Keep Up

IAM is fundamental to connecting users securely to applications and services across any device or location. However, traditional IAM platforms were not designed for today’s pace of change. Common pain points include:

• Slow deployment cycles: Monolithic IAM architectures are difficult to update, requiring lengthy release windows that slow down new service rollouts.
• Limited scalability: Traditional systems struggle to scale rapidly in response to sudden spikes in user demand or new business requirements.
• High operational cost: Manual configuration and maintenance of on-premises IAM infrastructure consume significant IT resources.
• Lack of cloud-readiness: Many legacy IAM solutions do not natively support multi-cloud or hybrid environments.

Modern IAM must be rearchitected for agility — supporting automated, continuous delivery pipelines and integrating natively with DevOps toolchains across any cloud provider.

Docker and Kubernetes: The Foundation of Modern IAM Deployment

Docker

Docker is a containerization platform that packages an application — along with its dependencies, libraries, and configuration — into a single portable container image. Containers run consistently across development, staging, and production environments, eliminating the classic “works on my machine” problem. For IAM deployments, this means identity services can be built once and deployed reliably on any infrastructure.

Kubernetes

Kubernetes is an open-source container orchestration system originally developed by Google. It automates the deployment, scaling, and management of containerized applications across clusters of machines. Key capabilities relevant to IAM include:

• Automated scaling: Kubernetes scales IAM service pods up or down in response to load, ensuring availability during traffic spikes.
• Self-healing: Failed containers are automatically restarted or rescheduled, maintaining high availability.
• Rolling updates: New IAM versions can be deployed with zero downtime using rolling update strategies.
• Multi-cloud portability: Kubernetes abstracts underlying cloud infrastructure, enabling the same IAM deployment to run on AWS, Google Cloud, or Microsoft Azure.

Together, Docker and Kubernetes give DevOps teams the tooling to deliver IAM services faster and more reliably, whether on-premises, in a hybrid setup, or across multiple cloud providers simultaneously.

The Business Case: DevOps and Identity Together

Large enterprises routinely face identity-related bottlenecks: slow time-to-market for new services, high deployment costs, and a shortage of specialized IAM expertise. A DevOps-native IAM platform directly addresses these challenges by enabling:

• Automated multi-cloud deployments: Infrastructure-as-code and Helm charts (or equivalent manifests) allow repeatable, version-controlled IAM deployments.
• Reduced configuration overhead: Pre-built container images and deployment templates minimize manual setup time.
• Faster iteration: CI/CD pipelines can include IAM configuration changes, allowing identity policies to evolve alongside application code.
• Support for millions of identities: Horizontal scaling via Kubernetes supports enterprise-grade identity volumes for customers, employees, and IoT devices.

“Microservice architectures, DevOps and agile development as new paradigms, and container-based deployments are changing the way IT is done. There are obvious benefits in moving to such architectures, such as increased flexibility and lower cost of operations, but also increased security.”

— KuppingerCole

ForgeRock’s Multi-Cloud DevOps IAM Approach

ForgeRock has designed its identity platform to be natively deployable via Docker and Kubernetes, targeting organizations that need enterprise IAM at cloud speed. Key aspects of the ForgeRock DevOps model include:

• Cloud-agnostic deployment: ForgeRock supports deployment on AWS, Google Cloud Platform, and Microsoft Azure without requiring vendor lock-in.
• Production-grade reference architectures: Pre-validated deployment blueprints reduce the design and testing burden for enterprise teams.
• Benchmarked performance data: Organizations can evaluate cloud deployment options against published benchmark results to optimize for cost, performance, and availability.
• Rapid identity provisioning: The containerized model is designed to support deploying millions of identities in minutes rather than days.

According to ForgeRock, customers adopting this DevOps deployment model have accelerated project timelines by three to six months and reduced implementation costs by approximately 25%. These figures are as reported by ForgeRock and have not been independently verified.

Practical Benefits for DevOps and Platform Engineering Teams

For DevOps and platform engineers evaluating an IAM solution, containerized deployment models offer concrete workflow advantages:

• GitOps compatibility: IAM deployment manifests can be stored in version control and applied through standard GitOps pipelines.
• Environment parity: The same container image runs in dev, test, and production, reducing environment-specific bugs.
• Faster disaster recovery: Stateless IAM pods can be relaunched rapidly from container images, improving RTO (Recovery Time Objective).
• Observability integration: Kubernetes-native monitoring (Prometheus, Grafana) can be applied to IAM service health and performance metrics.

Getting Started

Organizations evaluating a DevOps-oriented IAM strategy should consider the following steps:

1. Audit existing IAM architecture for containerization readiness and multi-cloud compatibility.
2. Evaluate IAM vendors based on native Kubernetes support, published deployment documentation, and available reference architectures.
3. Run proof-of-concept deployments on your target cloud platform(s) using vendor-provided Helm charts or Operator patterns.
4. Integrate IAM deployment into existing CI/CD pipelines to validate continuous delivery workflows.
5. Benchmark performance and cost across cloud providers before committing to a production topology.

ForgeRock provides multi-cloud and DevOps IAM resources, including on-demand webinars covering how to run IAM using Docker and Kubernetes. Refer to the ForgeRock website for current documentation and learning resources.

DevOps — which syncs, organizes and automates the pace of software releases — ‘is by default built for remote operations’ such as that required for the COVID-19 crisis. However, DevOps skills have been hard to find.

What effect is the tragic COVID-19 crisis — mandating the current scattering of employees across a corporate diaspora of home-bound workplaces, working from 10,000 home locations instead of one or two — having on collaboration and coordination for information technology endeavors? In recent years, collaboration has been defined as the essence of IT success. Not only have IT leaders and professionals been pressed to collaborate more closely everyone from the C-suite to the call center, but there has been special urgency for IT teams to coordinate and collaborate with each other.

Photo: Michael Krigsman
A report on COVID-era software development activities from GitHub points to some disruptions in development activity, but in general, developers are maintaining the pace. “Developer activity remains largely consistent or increased compared to last year,” according to Nicole Forsgren, the report’s author. “Developer activity-including pushes, pull requests, reviewed pull requests, and commented issues per user-shows slightly increased activity year over year. This suggests that developers have continued to contribute and show resilience in the face of uncertainty.”

What about organizational teams, especially involving operations, security and networking people, who typically have functioned in more on-premises environments?

This may be DevOps’ shining moment. The good news is DevOps — which syncs, organizes and automates the pace of software releases — “is by default built for remote operations,” relates senior technical architect Amit Kumar Gupta in a recent Medium post. “It has process oriented and automated software delivery method which doesn’t differentiate, if the team works from home, office or any other place. DevOps can very well adopt the changed caused by COVID-19 in the software industry. From the use of the distributed testing model to automated deployment mechanism, catching the early bug to capturing quality issues DevOps is all well suited to in these trying times.”

However, it’s time like these that really demand well-honed DevOps skills and experience — and that’s the challenge. The latest survey of 1,260 managers and developers out of the DevOps Institute, which finds the DevOps transformation journey is still very difficult for more than 50 percent of respondents: “Managing the people, processes and technologies associated with and necessary for a DevOps transformation are all difficult,” the report’s authors state.

In addition, the survey shows, finding and attracting people skilled in DevOps continues to be a challenge, cited by 58 percent of respondents. In addition, 48 percent report difficulties retaining them. The skill most sought-after includes process skills and knowledge (69%), which surpassed last year’s leading category of automation skills (67%). Another 61 percent need more “human” skills to boost their DevOps efforts.

For this work-at-home era, it means an ability to communicate frequently, and be able to reach out to various groups to keep things flowing, everyone in sync, and everyone feeling secure. The survey’s authors describe what is needed is a blending of skills, or “hybrid DevOps” skillsets — “skills from a wide area of fields which range from technology skills such as cloud infrastructure, to functional skills such as IT operations, to process and frameworks skills such as site reliability engineering or Agile. And last, having some exposure and skills around specific automation tools which one might have gained throughout their career or training, combined with business acumen, make a perfect hybrid DevOps engineer.”

Adapting and strengthening DevOps across remote teams calls for additional considerations:

Push Infrastructure and DevOps to the cloud: “When there is no certainty of when the situation will become normal and employees will reach office, we should move all the DevOps to cloud sooner than originally planned,” Gupta advises. “Push all DevOps tools into the cloud or use a cloud-native version of tools to support remote operation and monitoring of the DevOps process.”
Encourage more flexible ways of working and interacting. “This includes introducing flexible tools and processes to plan and track work such as enhancements, tasks, features, and bugs, which will help support developer productivity anywhere work happens,” says Forsgren.
Accelerate automation as much as possible. “When the organization sending all employees on work from home, we are realizing all the manual process which is giving the real pain,” says Gupta. “This is the time when machines should be more in charge of operations than humans. Automation can complete the task much faster — be it finding vulnerabilities in product, testing functionalities, or doing deployment to multiple environments simultaneously.”
Watch for burnout. The GitHub survey finds developers are working longer hours, but this could be due to the interspersing of family obligations while working from home. Consequently, “longer work days, more work, and more responsibilities at home means there is an increased likelihood of burnout,” says Forsgren. “Take breaks, try to create a sustainable workload — for yourself and your team — and create a supportive work community that includes clear boundaries for work and personal time.”
Ultimately, as the crisis passes, many employees may end up staying with their work-from-home arrangements, and their organizations will be more open to more flexible or remote work arrangements. Productivity will increase, software quality will be enhanced, and the cadence or releases will be more well-tuned to the business. We’ll all get through this, and technology initiatives will be that much stronger for it.

DevOps Is More Than a Buzzword

DevOps has become one of the most overloaded terms in software engineering. At its core, though, the promise is straightforward: faster delivery of changes with fewer production failures. For individual developers, that promise translates into concrete daily habits — not just organizational mandates handed down from management.

Gene Kim’s book The Unicorn Project frames the developer experience around what he calls The Five Ideals. Two of those ideals are especially actionable at the team level:

• The Third Ideal — Improvement of Daily Work: Continuously finding and fixing the friction points that slow down developers.
• The Fourth Ideal — Psychological Safety: Creating an environment where people can surface problems, try new things, and make mistakes without fear of blame.

When these two ideals are combined, teams find it easier to make confident changes to their codebases. And the good news is that the practical work required to implement them is well within reach — even for junior developers. Most of the improvements below take fewer than four hours to put in place.

Practical Changes That Add Immediate Value

The following tasks are ordered roughly from foundational infrastructure to day-to-day monitoring. Each one adds a layer of safety and visibility to your project.

1. Set Up a Continuous Integration Server

Tools such as Jenkins, TeamCity, GitHub Actions, or GitLab CI give you a reliable, automated foundation for everything else on this list. A CI server runs jobs triggered by code events — pull requests, merges, scheduled times — so that manual gatekeeping is replaced by consistent automation.

If your project doesn’t have a CI server yet, setting one up is the single highest-leverage action you can take. Without it, almost every other improvement is harder to sustain.

2. Create Automated Test Jobs

Once CI is in place, wire it up to your test suite in two ways:

• Pull-request jobs: Run tests automatically whenever a developer opens or updates a PR. Failing tests block the merge, preventing known breakage from reaching main branches.
• Nightly test runs: Schedule a full test run overnight. This surfaces slow-growing regressions that might not be obvious from a single PR and gives the team a reliable daily health check for the project.

Even if the test suite is small or partially broken, tracking the number of failing tests over time is valuable. You can’t improve what you can’t measure.

3. Add Code Coverage Reporting

Attach a code coverage tool to your automated test pipeline. Coverage reports answer two practical questions:

• Which parts of the codebase are exercised by tests, and which are not?
• Does the code I just changed have existing test coverage, or am I flying blind?

Coverage data helps the team prioritise where to write new tests and gives individual developers more confidence that their changes won’t silently break untested paths. It also opens a constructive conversation about testing standards without requiring anyone to audit the codebase manually.

4. Automate Deployments

Manual deployment processes are a major source of production incidents. Steps get skipped, environments diverge, and knowledge about how to deploy lives in one person’s head. Replacing a manual runbook with an automated deployment job on your CI server turns deployment into a one-click (or even zero-click) operation.

An automated deployment job also creates an audit trail: you can see exactly what was deployed, when, by whom, and from which commit. This is invaluable when something goes wrong and you need to identify what changed.

5. Instrument Your Application for Production Monitoring

Automated tests tell you whether code works as designed in a controlled environment. Production monitoring tells you whether it actually works for real users under real conditions. The two are complementary, not interchangeable.

Modify your project to emit metrics that matter to the application’s health — things like request latency, error rates, and throughput. With those metrics flowing into a dashboard, every developer on the team can check, immediately after a deployment, whether their change is causing problems in production.

A Real-World Example: Monitoring Without a Test Suite

Not every project is in a position to follow all five steps above in order. Sometimes you join a codebase with almost no automated tests and no clear path to adding them quickly.

In one such situation, a developer moved to a new web project that ran fine locally but had almost no test coverage. Rather than attempting to build a test suite from scratch — which would have taken months — the developer instead built a lightweight monitoring tool that captured all incoming HTTP requests to the site and recorded their response times and error codes.

The result: the team could immediately see how long each part of the website took to load and how many errors were being generated. After any change, the developer could check those metrics to detect regressions before they affected users — providing a meaningful safety net even without a formal test suite.

This is the Third Ideal in action: improve daily work with whatever tools are available, rather than waiting for ideal conditions that may never arrive.

Why Psychological Safety Matters for Technical Changes

The technical improvements above only deliver their full value inside a team culture where people feel safe to raise problems, admit mistakes, and experiment. If developers fear blame for failed deployments or broken tests, they’ll avoid making changes — and that risk-aversion is itself a form of risk.

Tooling like CI pipelines, automated rollbacks, and production dashboards supports psychological safety in a concrete way: when the system catches problems automatically and provides clear signals, individual developers are less likely to be singled out for blame. The conversation shifts from “who broke this?” to “what does the data tell us?”

Further Reading

If you want to go deeper on the ideas behind these practices, the following books are widely cited in the DevOps community:

• The Unicorn Project — Gene Kim
• The Phoenix Project — Gene Kim, Kevin Behr, and George Spafford
• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations — Gene Kim, Patrick Debois, Jez Humble, and John Willis

Each book approaches DevOps from a slightly different angle — narrative fiction, management perspective, and prescriptive handbook respectively — making them complementary rather than redundant.

What Is Mabl?

Mabl is an AI-assisted, automated testing platform focused on the front-end of web applications. Unlike traditional code-level test frameworks, Mabl tests are designed to validate user experience—verifying that an app behaves the way a real user expects, not just that the underlying code passes unit or integration checks.

As Mabl co-creator Dan Belcher explained: “Frameworks like Selenium test front-end code, not user experience. So all your scripts may pass, but from the user’s perspective the thing may still be broken.” For teams already invested in Selenium, Mabl supports importing existing Selenium test suites to ease migration.

New Integrations: GitHub, Bitbucket, and Atlassian Bamboo

The release described here focuses on extending Mabl’s reach into the daily developer workflow through integrations with popular code-hosting and CI/CD platforms. The core idea is shift-left testing—moving quality checks earlier in the development cycle so that issues are caught before they reach production or even staging.

GitHub Integration

• End-to-end Mabl tests run automatically as part of the pull request checks pipeline, blocking merges if tests fail.
• GitHub Actions can trigger Mabl test runs on commits, branch pushes, or PR events—no separate CI server required for this step.
• Tests can be snapshotted and version-pinned to specific workflow stages or product milestones, making it easier to reproduce exactly how tests behaved at a given point in time.

Bitbucket and Atlassian Bamboo Integration

• Atlassian Bamboo automation can also trigger Mabl tests, bringing front-end quality checks into teams using the Atlassian toolchain.
• Bitbucket repositories gain similar pipeline integration, allowing Mabl to slot into existing Bitbucket Pipelines workflows.

Developer-Centric Features

Beyond CI/CD pipeline integration, this release adds tooling aimed squarely at individual developers rather than dedicated QA teams.

Headless Local Test Runner

The headless local test runner lets developers execute front-end Mabl tests directly on their own machines during development—without needing to push code to a shared environment first. The runner operates in the background and surfaces issues without requiring the developer to monitor the test process manually.

Command-Line Interface (CLI)

A new CLI allows developers to configure and run Mabl tests alongside their regular development tasks. This makes it practical to run a targeted test suite from a terminal window without switching context to a browser-based dashboard.

Jira Ticket Automation for Regressions

When Mabl detects a regression or failure, it can automatically file a Jira ticket that includes:

• Full stack traces
• Screenshots or other test artifacts
• Enough context for a developer to reproduce the issue without manually re-running the test scenario

This reduces the back-and-forth between QA reporters and developers by embedding reproduction details directly in the issue tracker.

Pricing and Trial

Mabl’s pricing is available on request. At the time of this report, the platform offered:

• A 14-day free trial with full feature access
• Plans starting at 1,000 test runs per month, scaling upward based on volume and the auxiliary features required (such as cross-browser support beyond Chrome and Firefox)

Check mabl.com for current pricing, as plans and feature tiers will have changed since this article was originally published in April 2020.

Why This Matters for DevOps Teams

Integrating front-end UX testing directly into pull request workflows addresses a real gap in many CI/CD pipelines: automated tests often cover backend logic and API contracts thoroughly, but browser-rendered user flows are tested manually or only in dedicated QA sprints. By making these tests run on every commit—and by providing local and CLI tooling—Mabl reduces the cost of finding front-end regressions late in a release cycle.

The shift-left approach is especially valuable for teams practicing trunk-based development or deploying frequently, where catching a broken user flow after merge is significantly more expensive than catching it at the PR stage.

Overview

GitHub, the Microsoft-owned code hosting and collaboration platform, expanded its free tier in 2020 to include features that previously required a paid subscription. The move significantly lowered the barrier to entry for individual developers, open-source contributors, and small teams who need private repositories and basic CI/CD automation without a monthly bill.

What Changed

Before the change, accessing private repositories with multiple collaborators on GitHub required a paid plan, which started at around $7 USD per month. The free tier was largely limited to public repositories, making it less practical for proprietary or in-progress projects. GitHub’s CEO stated at the time that the company had been planning this shift for approximately 18 months before rolling it out.

The key updates to the free tier included:

• Unlimited private repositories — Free accounts can now create private repositories without needing to upgrade to a paid plan.
• GitHub Actions minutes — Free accounts receive 2,000 GitHub Actions minutes per month, enabling automated workflows such as CI pipelines, test runners, and notification triggers.
• Multiple collaborators on private repositories — Previously restricted on free accounts, collaboration on private repos became available, though some limits on the number of collaborators per private repository remained at the time of the announcement.

GitHub Actions: What the Free Allowance Covers

GitHub Actions is the platform’s built-in automation system. Workflows are defined in YAML files and can run on events such as pushes, pull requests, or scheduled intervals. Common use cases include running unit tests, building Docker images, deploying to cloud environments, and sending Slack notifications.

The 2,000 free minutes per month applies to Linux runners on free accounts. Windows and macOS runners consume minutes at higher multipliers, so teams using those environments will exhaust the free allowance more quickly. For small projects with lightweight CI pipelines, 2,000 Linux minutes is generally sufficient.

Who Benefits Most

The free-tier expansion is most impactful for:

• Individual developers and freelancers who want to keep client or personal work in private repositories without a monthly subscription.
• Small teams and startups that are early-stage and cost-sensitive, who can now use private repos and basic automation before committing to a paid plan.
• Open-source maintainers who may have private staging or development branches alongside their public repositories.
• Students and learners building portfolios that include both public and private work.

Paid Plans Still Offer More

While the free tier became substantially more capable, paid GitHub plans continue to provide additional value. These typically include higher Actions minute allocations, larger storage for GitHub Packages, advanced code review features, required reviewers, protected branches with more granular controls, and priority support. Organizations with larger engineering teams or compliance requirements will generally still need a paid tier.

Takeaway for DevOps Teams

GitHub’s decision to move private repositories and a meaningful Actions allowance to the free tier reflects a broader industry trend of platforms competing for developer adoption by removing friction at the entry level. For DevOps engineers advising small teams or evaluating tooling costs, GitHub’s free tier is now a realistic starting point for source control, basic CI/CD, and private collaboration — without requiring budget approval.

Teams that grow beyond the free-tier limits can evaluate GitHub’s Team or Enterprise plans at that point, with a clearer understanding of their actual usage patterns.

Those numbers signal a fundamental shift in how engineering organizations must operate. Skilled developers alone are no longer enough — the delivery pipeline itself has to carry much of the load.

The Six-Step Foundation of Every DevOps Pipeline

Andrew Davis, author of Mastering Salesforce DevOps and a practitioner at Copado, outlined at Dreamforce 19 that software deployments typically follow six steps, regardless of the platform or team size:

1. Understand what users need.
2. Build it.
3. Verify it works as intended.
4. Verify it integrates correctly with the rest of the system.
5. Confirm it does not break anything else.
6. Deploy it to users.

Although Davis presented in the context of Salesforce teams, the framework maps directly onto any software delivery organisation. The first two steps are where developers feel most productive — deep in the problem, with the full solution in working memory. Steps three through six, however, are where most teams stumble.

The Working-Memory Problem

Davis identifies a cognitive reality that every developer recognises: the state of flow. When you are deep in a feature, you hold the entire mental model of the system in your head. You can trace every dependency and reason about every edge case. That clarity is both the joy and the fragility of software development.

The problem appears when that context dissolves. A new project starts, a support ticket arrives, a sprint ends. Days or weeks later a defect surfaces — but the developer who introduced it has already moved on mentally. Reconstructing the original context takes significant time, and in a high-velocity release environment, three weeks of rework for a single regression can cascade into missed commitments across multiple teams.

Multiply one such incident by hundreds or thousands of concurrent change requests inside a large organisation, and the compounding risk becomes plain.

DevOps as a Three-Phase System

Davis simplifies the DevOps value chain into three phases:

• Development — Creating new features and capabilities.
• Innovation Delivery — The automated pipeline that moves code from development into production safely and repeatedly.
• Operations — Running and maintaining what is already in production.

The middle phase — innovation delivery — is the one that breaks down most often when left to manual processes. Automating it is the core purpose of a continuous integration and continuous delivery (CI/CD) strategy.

What an Effective CI/CD Strategy Looks Like in Practice

Based on Davis’s recommendations, a mature automated pipeline should meet three concrete criteria:

1. Trunk-based development at team scale. Every developer and team merges into a shared codebase — often called the trunk or main branch — at least once per day. Long-lived feature branches are a primary source of integration pain; short-lived branches merged frequently eliminate that class of problem.
2. Automated testing on every commit. The moment the codebase changes, an automated test suite runs. Human review is reserved for interpretation and escalation, not for catching regressions that a computer can find in seconds.
3. A ten-minute fix target for test failures. When a test fails or something breaks, the team resolves it within ten minutes. This constraint is not arbitrary — it keeps the broken state in working memory and prevents accumulation of unresolved failures that obscure the health of the codebase.

The speed of the feedback loop is critical. Davis argues that automated tests must return results to developers in under five minutes — ideally while the developer is still mentally engaged with the change. Tests that take hours to run are nearly as useless as no tests at all, because by the time results arrive the cognitive context is gone.

Configuration Drift: The Silent Threat to Continuous Delivery

Automating the build and test phases is necessary but not sufficient. Davis also highlights configuration drift as a chronic threat to continuous delivery — one that many teams underestimate until it causes a production incident.

Configuration drift occurs when environments diverge over time. Common causes include:

• Production-only hotfixes that are never back-ported to development or staging environments.
• Long-lived sandboxes that accumulate experimental changes, legacy data, and ad-hoc configurations that bear little resemblance to production.
• Manual environment changes made by multiple operators over months or years, with no automated record of what changed or why.

The result is an environment mismatch: code that passes every test in staging fails or behaves unpredictably in production because the two environments are not actually equivalent. The fix is to treat infrastructure and environment configuration as code — version-controlled, tested, and deployed through the same automated pipeline as application code.

Accelerating Development Requires Both Mindset and Tooling

Davis’s central argument — that accelerating delivery cycles requires “a combination of thinking and good tools” — resists reduction to a tool-selection problem. Purchasing a CI/CD platform without changing branching strategies, testing culture, or ownership models will not produce the outcomes organisations expect.

Conversely, the right mindset without automation at scale is equally insufficient. At the volume of change requests that modern engineering organisations handle, human coordination cannot substitute for a reliable, fast, automated pipeline.

The practical starting point for most teams is modest and sequential:

1. Establish a single shared branch and enforce daily integration.
2. Instrument automated unit and integration tests that run on every commit.
3. Measure and actively reduce the time from commit to test feedback.
4. Bring environment configuration under version control and automate provisioning.
5. Treat every manual step in the delivery pipeline as a candidate for automation.

None of these steps are novel, but their consistent execution at scale is what separates teams that ship reliably from teams that are perpetually firefighting.

Key Takeaways

• Release frequency is increasing industry-wide; manual delivery processes cannot keep pace.
• Developer working memory is finite — fast automated feedback loops preserve the context needed to fix defects quickly.
• An effective CI/CD pipeline requires daily trunk integration, automated testing on every commit, and rapid resolution of failures.
• Configuration drift between environments is a structural risk that only infrastructure-as-code practices reliably address.
• Tooling and organisational mindset must change together for CI/CD adoption to deliver measurable results.

I can’t state it strongly enough: Investing in simplicity is your best bet to bring about a successful IT project. Here are five left-field suggestions from my experiences as CTO, technical architect, and project lead.

1 – Could you not do it?

Old habits, inertia, or the fear of being blamed for not delivering something the customers may one day want are often the motivators for many feature requests from your product owners.

Being adept at Continuous Delivery allows you to educate people that, you’ll be able to deliver a backlog item WHEN it is needed. This on-demand ability enables you to say, ‘no, not now, but maybe later.’

SEE ALSO: The impact of working from home on developers

2 – Take the time to do less

Everything should be made as simple as possible, but no simpler.

This quote by Albert Einstein illustrates the importance of simplicity as he states that everything can benefit from this approach. However, this involves efforts as simplifying requires an understanding of what matters and where value resides. Walking the line between not enough and too much is driven by an experimentation mindset and proper tooling.

The short-term cost of striving for simplicity will more than pay for itself in the long run.

3 – The Single Responsibility Principle

Many of our best software engineers place Uncle Bob’s most famous principle in their top 3 criteria when designing software architectures. Strangely enough, our new hires fresh out of school also do the same.

SRP favours cohesion, lowers coupling, makes your code understandable by others, enables unit testing, and increases project velocity.

4 – MVPs are not just for products

Adopt an MVP approach at the feature level.

For instance, remove paging from your list screens. You can display the first 50 results instead and have the last line item say: Looking for something else? Refine your search results.

Poorly implemented infinite scrolling is detrimental to performance AND the user experience. Please don’t do it. Then, run away from smart folks asking you for multi-columns, combinatorial sorting on grids. The amount of testing to make sure everything works is insane.

SEE ALSO: Top 2020 trends for software engineers: Hired survey insights

5 – The cost of testing

Because quality is essential to your success, you test your software automatically before delivery. Right?

Have your developers write unit and end-to-end tests themselves. Then ensure your continuous integration pipeline enforces 100% test coverage. People are sensitive to the cost of complexity when their decisions impact them personally. Simplicity naturally emerges from this awareness.

Many other ideas could have made it onto this top five list: serverless, Kotlin, native cloud services, continuous delivery, DevOps, Kanban, and many more.

Simplicity is an ongoing quest, not a destination. It should be part of your culture and can’t only be a story on the JIRA board.

Simplicity also generates value, and value brings happiness. Your customers may not directly appreciate your simpler designs. However, steadily delivering high quality at a rapid pace is a sure winner.

The Norwegian architectural style also proves that simplicity is beautiful. Assigning a value to beauty is hard. But considering that mobile applications now make great design the new normal, forgoing this aspect in a product prevents you from meeting basic consumer expectations

Google Pulls the Plug on I/O 2020

Google announced via Twitter in March 2020 that it was cancelling its annual Google I/O developer conference entirely, citing concern for the health and safety of developers, employees, and surrounding Bay Area communities. The decision aligned with shelter-in-place orders issued by local Bay Area county authorities at the height of the early COVID-19 outbreak.

“Out of concern for the health and safety of our developers, employees, and local communities — and in line with recent ‘shelter in place’ orders by the local Bay Area counties — we sadly will not be holding I/O in any capacity this year.”

— Google, via Twitter

No Virtual Replacement Planned

Notably, Google made clear that it would not host a virtual or online replacement event for I/O in 2020 — a decision that distinguished it from some other tech companies that quickly pivoted to online-only formats. The company also cancelled Google Cloud Next, its other major annual conference aimed at enterprise customers and cloud partners.

Both conferences are key venues through which Google communicates new features, products, APIs, and strategic directions to the developer and business communities. Losing both events in the same year represented a significant disruption to Google’s typical product announcement cadence.

Impact on the Developer Community

For developers and DevOps engineers, Google I/O is typically the most important annual event to track announcements related to:

• Android OS and development tooling updates
• Google Cloud platform features and services
• Machine learning and AI APIs (TensorFlow, AutoML, etc.)
• Web platform standards and Chrome/V8 engine improvements
• Firebase, Flutter, and other cross-platform developer tools

Without a central conference event, Google committed to routing these announcements through its existing digital channels, including official developer blogs and community forums.

“Right now, the most important thing all of us can do is focus our attention on helping people with the new challenges we all face. Please know that we remain committed to finding other ways to share platform updates with you through our developer blogs and community forums.”

— Google

Broader Industry Context

Google’s cancellation was part of a wave of major tech conference cancellations in early 2020. The COVID-19 pandemic forced the entire industry to rapidly reconsider how developer relations, product announcements, and community engagement could be maintained without in-person gatherings. Many companies eventually adapted by adopting streaming keynotes, pre-recorded session libraries, and asynchronous community engagement — patterns that reshaped how developer conferences operate even after restrictions lifted.

For teams that rely on conference announcements to plan technology roadmaps and adoption cycles, the cancellation underscored the value of following official vendor blogs and RSS feeds as primary sources of truth — rather than depending solely on annual event cycles.

This article summarizes the core security practices every DevOps engineer should apply when working with Docker containers, regardless of the orchestration layer on top.

1. Treat the Container Like a Real Machine

A common misconception is that process isolation inside a container implies security. Isolation reduces the blast radius of a compromise, but it is not a security boundary on its own. Apply the same hardening principles you would to any server:

• Run as a non-root user. Add a USER instruction in your Dockerfile to drop privileges before the application starts. Running as root inside a container can translate to root on the host if container breakout occurs.
• Apply the principle of least privilege. Use Linux namespaces and cgroups to restrict what processes can see and consume. Docker exposes these through flags such as --cap-drop and --cap-add.
• Avoid world-writable directories and files. Audit filesystem permissions inside your images just as you would on a production server.
• Use read-only filesystems where possible. The --read-only flag prevents processes inside the container from writing to the container filesystem, limiting persistence opportunities for attackers.

# Example: non-root user in a Dockerfile
FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
COPY --chown=appuser:appgroup . /app
WORKDIR /app
CMD ["node", "server.js"]

2. Only Use Images from Trusted Sources

Pulling a public image is convenient, but you are trusting everything the image author chose to include. Malicious or misconfigured layers can introduce backdoors, outdated vulnerable packages, or unexpected binaries.

Practical guidelines:

• Prefer official or verified images. Docker Hub marks images as “Docker Official Images” or “Verified Publisher.” These go through additional review and automated scanning.
• Enable Docker Content Trust (DCT). Setting the environment variable DOCKER_CONTENT_TRUST=1 instructs the Docker client to only pull images that carry a valid cryptographic signature from the image publisher. This protects against tampered images in transit.
• Host a private registry. For production workloads, mirror approved base images in a private registry (such as AWS ECR, Google Artifact Registry, or a self-hosted Harbor instance) and restrict developers to pulling from there.
• Scan images for vulnerabilities. Integrate a scanner such as Trivy, Grype, or Snyk into your CI pipeline to catch known CVEs before images reach production.

# Enable Docker Content Trust for the current shell session
export DOCKER_CONTENT_TRUST=1
docker pull myrepo/myimage:latest  # will fail if image is unsigned

Note on Docker Hub: A security incident disclosed at DockerCon 2019 affected approximately 190,000 Docker Hub accounts, serving as a reminder that no hosted registry should be trusted without additional controls. Content trust and private mirrors add meaningful defence-in-depth.

3. Use Docker Bench for Security

Docker Bench for Security is an open-source shell script maintained by the Docker team. It audits your Docker host and running containers against the CIS Docker Benchmark—a community standard covering daemon configuration, image hygiene, container runtime settings, and more.

Running it is straightforward:

# Run Docker Bench for Security using Docker itself
docker run --rm --net host --pid host --userns host --cap-add audit_control \
  -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
  -v /etc:/etc:ro \
  -v /usr/bin/containerd:/usr/bin/containerd:ro \
  -v /usr/bin/runc:/usr/bin/runc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --label docker_bench_security \
  docker/docker-bench-security

Each check is rated as PASS, WARN, or INFO. You can pipe the output into your CI system to fail a build when critical warnings appear, making security checks a first-class part of your delivery pipeline. The repository is available at github.com/docker/docker-bench-security.

4. Limit Direct Access to Kubernetes Nodes

When Docker containers are orchestrated by Kubernetes, the security perimeter extends to the nodes themselves. Unrestricted SSH access to nodes is one of the most common and dangerous misconfigurations in Kubernetes clusters.

• Restrict SSH access. Limit node SSH access to a very small group of platform administrators. Where cloud-provider tooling allows, remove direct SSH access entirely and use systems like AWS Systems Manager Session Manager or GCP OS Login.
• Use kubectl exec for debugging. Developers who need to inspect or debug a running container should use kubectl exec rather than accessing the underlying node. This gives them a shell inside the container namespace without host-level access.
• Enforce IAM and RBAC policies. Define Kubernetes RBAC roles that grant only the permissions required for each team or service account. Avoid binding the cluster-admin role to user-facing accounts.

# Open a shell in a running pod without touching the node
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh

5. Isolate Workloads Using Kubernetes Namespaces and Policies

A compromised workload in a flat Kubernetes cluster can potentially reach every other workload. Namespaces and policy controls reduce this lateral movement risk.

• Use namespaces to segment workloads. Group related services into dedicated namespaces (e.g., payments, auth, logging) rather than leaving everything in default.
• Apply ResourceQuotas and LimitRanges. Namespaced resource quotas prevent a compromised or runaway container from consuming all cluster resources and affecting other tenants.
• Use Kubernetes RBAC authorization. Kubernetes’ built-in authorization plugin allows you to create fine-grained policies defining which users or service accounts can perform which actions on which resources, scoped to specific namespaces.
• Consider Pod Security Admission or OPA/Gatekeeper. Policy admission controllers let you enforce security standards (e.g., no privileged containers, no host network access) at the cluster level, before workloads are scheduled.

6. Protect the Network

Network controls are the last line of defence if a container is compromised. Even well-hardened containers should not be able to freely communicate with every other service in the cluster.

• Apply Kubernetes NetworkPolicies. NetworkPolicy resources define ingress and egress rules at the pod level. By default, Kubernetes allows all pod-to-pod communication; adding a default-deny NetworkPolicy and then allowlisting only the required connections significantly limits lateral movement.
• Use Ingress controllers to control external access. Define Ingress resources to explicitly declare which services are reachable via HTTP/HTTPS from outside the cluster, rather than exposing services directly with NodePort or LoadBalancer types.
• Consider a service mesh for mTLS. Tools like Istio or Linkerd can enforce mutual TLS between services automatically, ensuring that service-to-service traffic is encrypted and authenticated even within the cluster.
• Audit exposed ports. Review every container’s EXPOSE instruction and every Kubernetes Service definition. Eliminate any port that is not required for the service to function.

# Example: default-deny NetworkPolicy for a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

7. Keep Images and Dependencies Up to Date

Container images are point-in-time snapshots. An image built six months ago almost certainly contains packages with known CVEs by the time it reaches production, or shortly after. Treat image freshness as an ongoing operational concern:

• Rebuild base images on a regular schedule, not just when application code changes.
• Use minimal base images (e.g., alpine or distroless) to reduce the number of packages that need patching.
• Integrate vulnerability scanning (Trivy, Grype, Snyk) into both CI and as a recurring registry scan so you are notified when new CVEs affect images already in production.

Summary: Docker Security Checklist

Containers are powerful tools, but isolation is not invincibility. Each layer of your stack—image build, registry, runtime, orchestrator, and network—introduces its own risks and its own mitigations. Applying the controls above will meaningfully reduce your attack surface and make incidents easier to contain when they do occur.

Original article concept sourced from containerjournal.com. Expanded and updated for accuracy by the BestDevOps editorial team.

DevOps Is Becoming a Core Business Priority

DevOps and Fast IT adoption have been identified as two of the most significant growth areas in enterprise technology. According to a report from Venafi, a privately held cybersecurity company, this growth is being propelled by the widespread adoption of cloud computing and the operational benefits it brings: speed, agility, efficiency, and economies of scale.

While the Venafi report focuses primarily on security vulnerabilities in machine-to-machine communications, it also highlights how dramatically the pace of software delivery has accelerated — and why that acceleration is reshaping how engineering teams operate.

What Is DevOps (and Why Is It Sometimes Called Fast IT)?

DevOps is a broad set of concepts and cultural practices centered on building, evolving, and operating rapidly-changing, resilient systems at scale. As defined by Agile Admin, it encompasses “the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.”

The term Fast IT is sometimes used interchangeably with DevOps, emphasizing the speed at which software can be delivered when development and operations teams work in close collaboration. Both terms point to the same underlying shift: breaking down silos between teams and enabling faster, safer software delivery.

In practice, DevOps brings together popular frameworks and methodologies so they work in concert across the entire systems-development lifecycle. The result is a pipeline that supports:

• Agile development — iterative, incremental delivery of software in smaller, manageable segments
• Continuous integration (CI) — automatically building and testing code changes as they are committed
• Continuous delivery (CD) — ensuring code is always in a deployable state, ready for release at any time

Containers and Microservices: The Engine Behind Fast IT

A key enabler of Fast IT is the use of containers — cloud-based, self-contained runtime environments that package an application and all its dependencies together. Containers allow teams to run applications reliably across different computing environments without worrying about configuration drift or dependency conflicts.

Containers work hand-in-hand with microservices — an architectural approach where an application is broken into small, independently deployable modules. Rather than deploying one large monolithic application, teams deploy and update individual services independently, dramatically reducing the risk and complexity of each release.

Together, containers and microservices allow engineering teams to release software faster, recover from failures more quickly, and scale individual components of an application without scaling the entire system.

Container Adoption: A Signal of DevOps Maturity

As a measure of how rapidly DevOps practices were being adopted, the Venafi report cited a Gartner projection — made around mid-2018 — that 50 percent of enterprises would be running containers in production environments by the end of that year. A significant driver of this growth was the explosion of Internet of Things (IoT)-generated data, which placed new demands on scalable, modular infrastructure.

This rapid proliferation of containerized workloads and connected machines directly increased the complexity of infrastructure — and with it, the number of machines that needed to communicate securely with one another.

The Security Challenge: Machine Identity at Scale

The Venafi report’s central concern is what happens to security when the number of machines — containers, virtual machines, IoT devices, APIs — grows exponentially. Each machine that communicates with another must be authenticated. This is handled through machine identities: cryptographic credentials such as TLS/SSL certificates and SSH keys that verify a machine is who it claims to be.

As DevOps pipelines scale and containers spin up and down dynamically, managing these machine identities becomes genuinely difficult. The risks include:

• Certificates expiring unnoticed, causing outages
• Poorly managed SSH keys granting unauthorized access
• Lack of visibility into which machines hold which credentials
• Insufficient automation for certificate issuance and renewal at container speed

For DevOps teams, this means that security practices must evolve alongside delivery pipelines. Automating certificate lifecycle management and integrating secrets management tools into CI/CD workflows are increasingly important steps for teams running containers in production.

Key Takeaways for DevOps Teams

• DevOps and cloud adoption are deeply linked — the speed and scale that cloud enables are primary drivers of DevOps growth.
• Containers and microservices are central to Fast IT, enabling faster releases and more resilient systems.
• Rapid container proliferation introduces machine identity management as a critical — and often overlooked — security discipline.
• DevOps maturity requires security to be embedded in the pipeline (DevSecOps), not bolted on after deployment.

The growth trajectory for DevOps practices has only continued since this report was published in 2018. For teams still building out their pipelines, the fundamentals remain the same: automate delivery, embrace incremental change, and treat security as a first-class concern from day one.