Security

When Docker first appeared, it was loved for the slogan: “Build once, run anywhere”. Developers stopped hearing the phrase “it works on my machine, but not on the server.” But along with convenience came a new threat.

A container is not just your application. It’s a whole mini-operating system (OS) with its own libraries, utilities, and system calls. And if you don’t look after that OS, you leave hackers with a huge door wide open.

Imagine you are building a house. You designed the walls yourself, checked every brick, and made sure you didn’t leave the keys in the lock. But what if the concrete you bought from a third-party supplier starts crumbling over time? Or the finished window frames you installed have hidden defects?

In modern development the situation is exactly the same. The average application today is 80–90% made up of Open Source libraries. You write only a small portion of the code (the tip of the iceberg) that orchestrates a huge mass of someone else’s code hidden “under the water”.

Have you ever wondered how experienced programmers find bugs in someone else’s code just by looking at it? They look for patterns. They know that if user data goes straight into an SQL query — that’s bad. If a password is compared with a plain == instead of a secure function — that’s a risk.

But a person can’t review 100,000 lines of code without missing something. This is where SAST (Static Application Security Testing) comes in.

Imagine this scenario: you’ve been working on a cool project all night. By 4 a.m. everything is ready, you do a final git push and go to sleep with a clear conscience. In the morning you find your AWS balance is zero and a miner is running on your servers. What happened? It turns out you left a line in one of the files: AWS_ACCESS_KEY_ID = "AKIA...".

This is a classic mistake thousands of developers have made. In this article we’ll look at why “just deleting the password” won’t help and how to set up automatic protection that will physically prevent you from making the mistake.

Write a Dockerfile simply: FROM node, COPY ., CMD run. It works, and for local tests this is often enough. But when such an image reaches CI/CD or, God forbid, production, problems begin: builds take forever, the image weighs gigabytes, and the security team grabs their heads.

The difference between “it works” and “it works correctly” is huge. Let’s go through four levels of optimization that separate a hobbyist hack from a reliable engineering solution.

OpenVPN is a reliable and time-tested VPN protocol that allows organizing secure remote access to a local network. MikroTik RouterOS supports OpenVPN in server mode starting from version 6.x (TCP), and from version 7+ — also UDP, but with a number of architectural limitations:

• mandatory authentication by username/password even when using certificates;
• limited list of ciphers and algorithms;
• absence of some features of “classic” OpenVPN.

Despite this, OpenVPN on MikroTik remains a popular solution — especially in scenarios where clients do not support WireGuard or compatibility with legacy systems is required.

If I were sent to a deserted digital island and allowed to take only one networking utility — I would unhesitatingly choose Netcat.

The official documentation (man nc) dryly states: “a utility for reading from and writing to network connections using TCP or UDP.”
In practice it’s the Swiss army knife of the network engineer, replacing dozens of specialized programs.

The article uses examples for OpenBSD netcat — this is the one that ships by default in Ubuntu 20.04+, Debian 10+, Fedora, Arch, Alpine and most modern distributions.

Read more

If your business works with users from Russia, the question of where personal data is stored concerns you directly. Phones, names, email addresses, form submissions, employee data — all of this falls under strict localization requirements.

Many companies have lived for years in a “gray area”: data seemed to be stored both in Russia and abroad, and responsibility was blurred. But as of July 1, 2025 the rules changed so much that many common technical schemes are now considered a direct violation of the law.

If you use n8n for automations involving large language models (LLM), you probably know not only about their huge capabilities but also about the risks. LLMs remain a “black box”: they can accidentally disclose personal data, generate toxic content, or fall victim to prompt injection.

Until recently, you had to “wrap” an AI workflow with many IF nodes and complex Regex checks. It was cumbersome and unreliable.

Since version 1.119.0 n8n includes the Guardrails node — and it’s truly a game-changer. It’s your personal security layer that you can place at the input and output of any AI process.

In a world where data privacy and access to resources are often restricted by geoblocks or corporate policies, tools like ProxyChains become indispensable assistants. ProxyChains — or more precisely its modern fork ProxyChains-NG — is an open utility for Unix-like systems (Linux, macOS, etc.) that allows routing the network traffic of any application through a chain of proxy servers. It is especially popular among developers, pentesters, and security enthusiasts. In this article we’ll cover what ProxyChains can do, why it’s useful for developers, provide usage examples, and discuss its limitations.