Towards the end of 2017, there was a major shift in the malware scene. As cloud-based technologies became more popular, cybercrime gangs also began targeting Docker and Kubernetes systems.

SECURITY
Cyber security 101: Protect your privacy from hackers, spies, and the government
Cyber security 101: Protect your privacy from hackers, spies, and the government

Simple steps can make the difference between losing your online accounts or maintaining what is now a precious commodity: Your privacy.

Read More

Most of these attacks followed a very simple pattern where threat actors scanned for misconfigured systems that had admin interfaces exposed online in order to take over servers and deploy cryptocurrency-mining malware.

Over the past three years, these attacks have intensified, and new malware strains and threat actors targeting Docker (and Kubernetes) are now being discovered on a regular basis.

But despite the fact that malware attacks on Docker servers are now commonplace, many web developers and infrastructure engineers have not yet learned their lesson and are still misconfiguring Docker servers, leaving them exposed to attacks.

The most common of these mistakes is leaving Docker remote administration API endpoints exposed online without authentication.

Over the past years, malware like Doki, Ngrok, Kinsing (H2miner), XORDDOS, AESDDOS, Team TNT, Xanthe, and others, have scanned for Docker servers that left the Docker management API exposed online and then abused it to deploy malicious OS images to plant backdoors or install cryptocurrency miners.

The latest of these malware strains was discovered last week by Chinese security firm Qihoo 360. Named Blackrota, this is a backdoor trojan that is basically a simplified version of the CarbonStrike beacon implemented in the Go programming language.

Only a Linux version was discovered until now, and it is unclear how this malware is being used. Researchers don’t know if a Windows version also exists, if Blackrota is being used for cryptocurrency mining, or if it’s used for running a DDoS botnet on top of powerful cloud servers.

What is known is that Blackrota relies on developers who have made a mistake and accidentally misconfigured their Docker servers.

The lesson from Blackrota and past attacks is that Docker is not a fringe technology anymore. Threat actors are now targeting it on purpose with at-scale attacks on a near daily basis.

Companies, web developers, and engineers running Docker systems are advised to review the official Docker documentation to make sure they have secured Docker’s remote management capabilities with proper authentication mechanisms, such as certificate-based authentication systems.

Currently, there are plenty of tutorials around to guide even the most inexperienced developers with step-by-step guides.

With Docker gaining a more prominent place in modern-day infrastructure setup, with attacks on the rise, and with the number of malware strains that target Docker systems growing by the month, it’s time that developers took Docker security seriously.

Diffblue, a UK-based startup founded by University of Oxford researchers and focused on automating software development through artificial intelligence (AI), today announced that it is making a free version available for developers on open source software projects.

The new company launched its first product, an AI-powered Java unit testing solution, in September. Diffblue’s Community Edition IntelliJ IDEA plugin, available now on the JetBrains marketplace. interactively writes unit tests for Java applications, increasing test coverage, and helping devs find regressions in future code changes.

“How Diffblue works for experienced Java hands, is it uses reinforcement learning to automatically write regression unit tests for Java apps,” a company spokesperson explained in an email. “They reflect the current behavior of the application and so can be used to find regressions in new code commits, and it writes test that look like a human wrote them. Diffblue Cover (the company’s flagship product) makes full use of Spring test infrastructure and mocking to write canonical Spring tests. Unlike other tooling, Cover can also automatically maintain its test suite as the code evolves, updating just the tests that need to be re-written after a change.”

In the first 15 days after the Diffblue Cover Community Edition launch, developers wrote more than 21,000 Java unit tests, which saved about 580 days of manual effort (assuming 10 minutes per test, 6 hours of productive time per developer day), the company said.

Diffblue Cover is based on reinforcement learning (RL) research conducted at Oxford by the company’s founders. RL is a method of training machine learning (ML) models to take the best action to maximize reward in a particular situation–in other words, to learn by trial and error. It’s the same method used in AlphaGo, the Alphabet subsidiary DeepMind’s software that beat the human world champion player of Go.

Where most unit test generators create boilerplate code for tests that must be completed by developers to get functioning tests, the company explained in a statement, Cover is able to create complete human-readable unit tests that are ready to run immediately. In fact, the company claims that its solution creates Java tests at speeds 10X-100X faster than humans that are also easy for developers to understand, and automatically maintains the tests as the code evolves, even on applications with tens of millions of lines of code.

“Our goal is to be the leader in applying AI to code, starting with unit tests, the critical foundation that allows developers to more frequently ship higher quality software,” said Diffblue CEO Mathew Lodge, in a statement. “We help organizations reduce time to ship, ship more often, and ship code with fewer defects while freeing up developers to focus more time on the most engaging part of their jobs. Companies on the journey to digital transformation, especially during this COVID pandemic, can’t keep up with the rapid software changes required to reorient their businesses. Automating unit testing on new and legacy code can accelerate their journey to success.”

The free version (downloadable from the JetBrains marketplace) was created for developers using the IntelliJ IDEA integrated development environment, the most popular IDE for enterprise Java. The commercial editions install in less than five minutes, the company says, and provide 100 percent automated Java unit test writing and integrate directly into continuous integration and delivery (CI/CD) systems. The technology behind Diffblue Cover can also be extended to support other popular programming languages, the company says, such as Python, JavaScript, and C#.

“As enterprises all over the world increasingly emphasize the velocity of their application development processes, unit testing becomes more and more critical,” said RedMonk analyst Stephen O’Grady, in a statement. “This is particularly true for the millions of enterprise Java developers worldwide, who are charged with maintaining countless critical applications for businesses large and small. The challenge is that tests can be tedious to write, and developers would prefer to devote their time and attention to writing code if the task of writing tests can be automated. This is the precise opportunity that Diffblue was built for.”

Building a tool for Kubernetes developers means solving a bunch of problems (e.g., multiple clusters, kubeconfigs, secrets, kubectl functionality, how to represent the hierarchy of abstractions inside a cluster, etc.) and creating a user experience that promotes speed. A good dashboard lets you select from among multiple clusters and:

See the states of everything and work with whatever you’re permissioned to access (this translates into zero need for IT operators to centrally administer dashboard-specific permissions).
Drill into abstractions—see what’s running and what’s dependent on what.
Identify what’s relevant to your work right now—i.e., let you constrain context.
Accelerate your work: navigate around local directories, control local applications (e.g., Git, VSCode, etc.) from the command line, view/edit/reapply abstractions, grab container logs, log into container shells, etc.
Browse and apply Helm charts, etc.
And maybe also maintain several contextualized work-sessions in parallel (different projects, different clusters, etc.), so you never need to spend cycles finding your place.
What’s interesting is that solving these problems well means you’ve already solved some important additional problems. You know how to create and maintain contexts in which work can happen efficiently. And in so doing, you’ve mastered important aspects of the integration puzzle that turns a ‘context’ into a ‘workflow.’

Specifically, you’ve mastered the terminal, which is the interface most devs use to coordinate local (and remote) applications, CLIs, and the artifacts they create and consume. You’ve mastered the Kubernetes API, and through that, the substrate of tools (e.g., Helm) used to configure, deploy and lifecycle-manage applications, components and services, including the integrated, non-Kubernetes-native solutions on which you depend to support your bespoke applications (such as [third-party] Ingress or Message Queue or Metrics or Database, etc.).

This given, a strong Kubernetes dashboard can, in principle, become a full-fledged Kubernetes IDE by creating some relatively simple integration ‘glue’: code that lets contributors build ‘extensions’ in a simple, secure, standardized way. A way that lets extensions automate what you, yourself could do manually (assuming you knew how).

For a specific kind of app, say an ingress controller, this might involve:

Inheriting your permissions (or, in some cases, organizing and remembering separate permissions for certain services).
Discovering relevant applications/services (i.e., ingress controller components, sidecars, manager workloads, operators, etc.) in the cluster you’re now looking at.
Dynamically representing the state of those ingress components within the ‘dashboard’ webUI.
Extending the webUI and/or dashboard configuration dialog(s) with bespoke sections that simplify ingress configuration.
Plus other features, such as automatically extracting parts of, or the whole hierarchy of ingress objects so you can store these files locally and place them in version control.
It’s easy to imagine extending this fundamentally-simple (in principle; obviously, it can be tricky to implement in practice) model to let extensions drive all sorts of components and provide a wide range of valuable services to developers. Assuming your dashboard already knows how to import and apply Helm charts; it should be simple to create the extension equivalent of an IaaS database-as-a-service (DBaaS) framework, where the extension maintains a perpetually-updated list of trusted sources for 15 major databases and provides basic configuration options and one-click installation for each type, bookmarking access to product-specific configuration tools for further work.

Such an arrangement around an extensible dashboard could benefit the entire community, including:

Developers: Who are free to install (or build) open source extensions for their favorite tools, thus creating flexible, highly-customizable, and efficient working environments within the dashboard. (Working environments that can, in principle, be packaged and shared among, for example, developers collaborating on a given project).

Operators: Who are also free to create and share collections of extensions, so able to ‘soft-standardize’ working environments without making developers feel as though they’re being dictated to. Operators can, meanwhile, closely-manage RBAC permissions on any cluster, ensuring that dashboard+extension users are never able to go ‘out of bounds.’

CNCF ecosystem participants: Building extensions to manage components under inherited RBAC permissions from within a dashboard environment that supports terminal and Kubernetes API/kubectl sessions, and that also provides sophisticated, widget-rich weblike functionality for visualization and interaction, is easier than maintaining many integrations to specific development tools. It’s also potentially far more useful to developers, who can adopt subsystem/tool-specific extensions as part of their evolving workflows—improving quality of life as opposed to learning yet another UI, CLI, or REST API. Making tools and components more consumable by developers (and operators) can be an important selling proposition in an ecosystem dominated by YAML and crude interaction principles (e.g., edit YAML, change YAML, reapply YAML, rinse, repeat).

The critical factor, of course, is whether such an extensible dashboard can reach sufficient critical mass to become the preferred way of packaging functionality and accelerating development—completing its evolution into an ‘IDE,’ and perhaps even becoming a sort of framework.

Here, it feels to me as though what’s most important is that the dashboard sits where a certain subset of Kubernetes coders and operators do most of their work, which is in the tight, iterative loop between the desktop and the cluster. This is quite different from classic IDEs, built around code editors. Obviously, the latter are still vitally important when work is focused on new application coding or on maintaining mature application code, particularly where back-end processes are fully automated with CI/CD.

But as most Kubernetes-centric developers are coming to realize, there tend to be big gaps (and latencies) in this model that only a dashboard-centric, context-aware, extensible IDE is ‘fast enough’ to fill. Once the containers are built, people need tools purpose-designed for iteratively tweaking the abstractions that put those containers to work. Once those YAML files are tested and made part of application lifecycle and/or infra-as-code repositories, and when the CI/CD has been extended to apply them automatically (in our ideal universe), there’s now forensics, break/fix and other new tasks that need to happen on that bleeding edge of dev-to-cluster iteration.

GitHub has spruced its GitHub for mobile platform with new features that it hopes will make code review easier and faster for developers.

The improvements include an overhaul of the code review experience, including the ability to toggle line wrapping on and off – this something that the community demanded.

Another improvement relates to the way code commits appear to others. Users can change an email associate with every merge, and they can also edit the commit description.

Finally, GitHub for mobile also features the ability to comment on multiple lines of code by long pressing to enable multi-select. GitHub says this makes it easier to explain how a suggestion fits in context.

A new ‘Jump To’ icon also helps to navigate reviews that span multiple files.

GitHub says these developments reflect the fact that more developers are turning to mobile apps to get their coding done.

GitHub for mobile was launched in March. Statistics show that developers have made almost 700,000 code reviews and more than 350,000 merges through the platform.

GitHub for mobile is available on the App Store and Google Cloud for individuals, Team, and Enterprise Cloud users.

GitHub is also one of three companies who have helped to teach digital skills to more than 10 million people worldwide.

Alongside Microsoft and LinkedIn, GitHub joined the digital skills initiative when it launched in June 2020.

The initiative has three aims:

(1) The use of data to identify in-demand jobs and the skills needed to fill them;
(2) Free access to learning paths and content to help people develop the skills these positions require;
(3) Low-cost certifications and free job-seeking tools to help people who develop these skills pursue new jobs.

Since then, more than 1.5 million people in Asia Pacific alone have engaged with the initiative.

Microsoft New Zealand’s national technology officer Russell Craig says, “COVID-19 has accelerated the need for upskilling and transformed the future of work for communities in New Zealand.”

“Addressing and closing the skills gap is an urgent task, key to inclusive economic recovery and digital transformation. While we are close to the halfway point of our goal to help 25 million people globally, we continue to strive in our commitment to drive societal progress and help improves lives of people in New Zealand by advancing their capabilities and expertise.”