DEV Community: Ihor Klymchuk

High-Level Security Framework for Development Companies

Ihor Klymchuk — Tue, 10 Mar 2026 11:21:15 +0000

A company can build its reputation over many years and lose it in a single security incident.

Security is one of the most important and difficult processes to implement in a company. It rarely generates direct revenue, but ignoring it can lead to severe financial, legal, and reputational damage.

Security cannot be implemented once and forgotten. It must be integrated into daily development processes and continuously improved.

Below is a high-level framework companies can use to establish security practices.

1. People and Security Culture

Security always starts with people.

You can implement the best tools and processes, but if the team does not understand security principles, incidents will still happen.

Developers have access to internal services, infrastructure, and source code. Many security incidents occur because employees are unaware of basic security rules.

Examples include:

the Twitter admin tool breach (2020) caused by phone phishing (source)
source code leaks due to credentials committed to GitHub (source)

Even experienced developers sometimes lack basic security knowledge.

Security education

Developers should understand common vulnerabilities and secure coding practices.

Essential resources:

OWASP Top 10 (https://owasp.org/www-project-top-ten/)
PortSwigger Web Security Academy (https://portswigger.net/web-security)
Practical labs such as OWASP Juice Shop or WebGoat (https://owasp.org/www-project-juice-shop/ or https://owasp.org/www-project-webgoat/)

These resources help developers understand real-world attacks.

Certifications

Certifications are not always required but they help build security awareness.

For example:

cloud certifications (AWS / GCP / Azure)
framework certifications
security-focused certifications

These programs usually include security fundamentals.

Internal security workshops

Companies should run internal sessions covering:

common vulnerabilities
secure coding practices
company-specific security rules
lessons learned from past incidents

Some companies also establish Security Champions — developers responsible for security awareness inside each team.

2. Secure Development Practices

Security must be integrated directly into the development process.

Secure coding standards

Teams should follow recognized security standards such as:

OWASP Top 10
OWASP Secure Coding Practices

Code reviews should include security considerations, not just functionality.

Threat modeling

Before implementing major features, teams should evaluate potential risks.

Questions to ask:

What data are we protecting?
Who might attack the system?
What could go wrong?

Threat modeling frameworks like STRIDE help identify risks early in the design phase.

Dependency security

Modern applications rely heavily on open-source libraries.

New vulnerabilities are discovered constantly, so automated monitoring is essential.

Tools:

Dependabot by GitHub
OWASP Dependency Check
Snyk

These tools automatically detect vulnerable dependencies.

Static code analysis

Static analysis tools help identify vulnerabilities during development.

Examples:

SonarQube — open-source and enterprise versions are available. Supports many languages
Snyk
Checkmarx
Semgrep — free and paid versions available

These tools can be integrated into CI pipelines.

3. Secure Development Environments

Development environments must prevent data leaks and unauthorized access.

Masking production data

Developers should not have direct access to production data unless necessary.

Instead, companies should generate sanitized database copies where sensitive information is masked.

Examples of masking tools:

VeilDB (veildb.com) — anonymization and data masking tool with the ability to securely share across the team
Greenmask — open-source data anonymization for Postgres
Tonic.ai — data faker

This allows developers to work with realistic datasets without exposing customer data.

Disk encryption

Company laptops should enforce disk encryption.

If a device is lost or stolen, encryption prevents attackers from accessing stored data.

Endpoint management

Companies often use device management tools to enforce:

OS updates
disk encryption
security policies

Examples include Intune, Jamf, and other MDM systems.

VPN and zero-trust access

Access to internal infrastructure should be restricted.

Common solutions include:

WireGuard — free and easy-setup VPN
Tailscale — good for engineering teams
Cloudflare Zero Trust

These tools ensure internal services are not exposed publicly.

Virtual desktop infrastructure

Some enterprise organizations prevent local development entirely.

Developers work inside virtual desktop environments (VDI) where all data remains within company infrastructure.

4. Identity and Access Management

Access control is one of the most critical security mechanisms.

Single Sign-On

Companies should centralize authentication through SSO providers.

This simplifies user management and improves security.

Examples:

Keycloak — open-source SSO provider
Okta — an enterprise-level SSO provider for applications
Microsoft Entra ID — company-level SSO
Google Workspace — company-level SSO

Principle of least privilege

Employees and services should receive only the permissions they need.

Examples:

Bad practice:

Developer accounts with full cloud administrator access.

Better practice:

Developers receive read-only access to logs and limited deployment permissions.

Password management

Companies should enforce password policies:

never share credentials via messaging platforms
never store passwords in documents or tickets
avoid credentials in code repositories

Password managers should be used for secure credential storage.

Two-factor authentication

Two-factor authentication should be mandatory for all critical services:

Git repositories
cloud infrastructure
internal tools

5. Secure Deployment and CI/CD

Deployment pipelines are powerful and must be protected.

Git repository security

Important practices include:

protected main branches
pull request workflows
mandatory code reviews
restricted repository access

These controls prevent unauthorized changes to production code.

CI/CD security

CI pipelines often contain sensitive credentials.

Recommended practices:

avoid long-lived tokens
restrict pipeline permissions
rotate secrets regularly
run security checks during builds

6. Infrastructure Security

Infrastructure configuration is another major attack surface.

Network segmentation

Production environments should be separated from development and staging environments.

Critical systems such as databases should not be publicly accessible.

Secrets management

Credentials should never be stored in source code or configuration files.

Instead, companies should use secrets management systems.

Examples:

1password.com
bitwarden.com — free version is available
psono.com — self-hosted version is available

These systems allow secure storage and automatic rotation of credentials.

Encryption

Sensitive data should be encrypted:

in transit (TLS)
at rest (database encryption, encrypted backups)

7. Monitoring, Logging, and Incident Response

Security monitoring helps detect attacks and suspicious behavior.

Logging

Important events to log include:

authentication attempts
permission changes
administrative actions
failed requests

Logs should be centralized and analyzed.

Common tools:

Datadog
Elastic Stack — clasic stack: Elasticsearch, Kibana, Beats, and Logstash
Splunk

Incident response planning

Security incidents will eventually occur.

Companies should define an incident response process that includes:

detection
containment
investigation
recovery
post-incident analysis

Without preparation, companies often react too slowly during attacks.

Backup and recovery

Reliable backups are essential to recover from incidents such as ransomware.

Best practices include:

encrypted backups
immutable backup storage
regular recovery testing

Bonus

If you made it this far, here’s a small bonus.

I summarized the framework from this article into a single-page security poster you can share with your team.

Conclusion

Security is not a single tool or configuration.

It is a continuous process involving people, development practices, infrastructure, and operational monitoring.

Companies that integrate security into their development culture significantly reduce the risk of costly security incidents.

Security must evolve together with technology, development processes, and emerging threats.

How a $150,000 Mistake Changed the Way I Handle Production Data

Ihor Klymchuk — Tue, 03 Mar 2026 13:11:00 +0000

Story 1

A long time ago, when I was working as a developer at an e-commerce company, we received an urgent Slack message: something had gone terribly wrong — customers were being charged extra money.

What happened?

The client had a subscription-based web store. A tech lead updated the staging database but forgot (or didn’t realize) that cron jobs were still enabled. Instead of cleaning the data, he simply created a dump from production and imported it into staging.

As a result, subscription billing ran again.

Around $150,000 was charged from customers’ accounts.

It was chaos. Thousands of apologies. Weeks of refunds. Damage control calls every day.

After that incident, the company introduced strict rules:

Always clean production dumps before importing.
Disable all cron jobs.
Replace external service credentials with sandbox ones.

But it was too late.

The reputation damage had already been done.

Story 2

When it happened, I was just a developer and wasn’t involved in that process — but I remembered the lesson.

When I became a Tech Lead, I made sure developers never received backups with raw production data. Staging and dev servers were also updated with trimmed backups only.

Later, when I moved to a CTO role, I implemented internal tooling to prevent exactly these kinds of incidents.

Did it help? Partially.

A developer from an offshore team wasn’t aware of our processes and updated the staging database with production data. This broke the search entirely, since it was powered by a third-party service, and all search index links were pointing to the staging website.

All customers were redirected to the staging website, which, of course, affected the sales.

We fixed it quickly. And since it wasn’t our fault operationally, our reputation stayed intact.

But the pattern was obvious.

The problem wasn’t people.

The problem was the process.

The Real Problem

I started asking friends in other companies how they handle database sharing.

The answers were surprisingly similar:

“We have some internal scripts.”
“We trim data manually.”
“We have rules — but it’s up to developers to follow them.”

In most cases, production data handling depends on human discipline.

And humans make mistakes.

Looking for a Solution

Back in 2020, I tried to find a proper solution.

There were almost no universal tools available. Existing solutions were either:

Enterprise-only
Stack-specific
Or extremely limited

So I decided to build one.

Solution

VeilDB (https://veildb.com/) is an open-source solution that helps anonymize and mask sensitive data from databases and safely share processed dumps with your team.

You can easily:

replace user’s name with some value
email → faker replacement,
generate random numbers for a credit card.

This perfectly works for outsourcing teams, e-commerce, and agencies managing multiple client environments. It also works for individual projects, ensuring developers don’t get access to the real data.

VeilDB is fully open-source.

👉 GitHub: https://github.com/veildb-tech/service

👉 Documentation: https://veildb.gitbook.io/

👉 Quick Start Guide: https://veildb.gitbook.io/veildb-docs/getting-started/

How does it work?

It consists of three layers:

1. Service Layer (UI)

A web interface where you configure:

Masking rules
Permissions
Schedules
Webhooks

2. Agent Layer

A CLI-based agent installed on your server that processes databases.

Important design principle:

The Service layer never receives actual data — only database schema.

The Agent:

Creates a dump
Restores it inside isolated Docker infrastructure
Applies masking rules
Generates a sanitized dump
Removes temporary data

It never works directly with the original database.

Multiple agents can be connected to a single Service instance.

3. Client Layer

A lightweight CLI tool installed on developers’ machines to securely download processed dumps.

How the Workflow Looks

Admin configures masking rules and schedules in the UI.
The Agent checks the queue and retrieves processing rules.
The Agent creates and processes a dump in isolation.
Developers download only sanitized backups.

For developers, the flow is simple.

Under the hood, several critical security checks happen:

The Service verifies whether the developer has access to a specific database.
The Service issues a temporary token.
The Client uses this token to download the dump from the Agent.
The Agent validates the token before allowing the download.
All communication is encrypted.

Conclusion

Setting up VeilDB may take some initial effort.

But it’s a small price compared to:

Charging customers by mistake
Corrupting external services
Leaking sensitive data
Damaging your company’s reputation

Production data is powerful.

It should never be shared without protection.

The Rise and Decline of Magento in E-Commerce: From Open Source Giant to Niche Player

Ihor Klymchuk — Thu, 04 Sep 2025 09:46:02 +0000

I started working with Magento in 2014 at a small company that develops extensions for Magento. Over the past decade, I saw incredible growth in 2020 due to COVID-19, and now I notice that many of my former colleagues are struggling to find jobs, and overall, the number of e-commerce projects based on Magento is decreasing.

Does it mean that Magento is dying?

Based on the open statistics, depending on the region, Magento holds up to 7–9% of global e-commerce, compared to 13% in 2015 (information based on the BuildWith statistic https://trends.builtwith.com/shop/Magento)

Builtwith Magento Usage Statistics

Additionally, I've noticed that Magento's popularity is declining, and friends from other companies report a decrease in the number of Magento projects.

Well, the problem could be in companies, doesn’t it? So I asked my friend

Hey, you have built one of the most popular Magento extensions. What’s going on with it?

.. and he provided me with such a graph:

Another graph (I promise, the last one) is simply Google interest

From all these graphs, it is obvious that the popularity of Magento is decreasing. But why? I have spent a lot of time investigating the issue and exploring the e-commerce market, especially Magento.

I decided to review and recall the history of Magento to understand why such a big project and platform are losing their popularity. That’s just my personal opinion.

What is Magento?

Let’s start with a quick overview of what Magento (also known as Adobe Commerce) is.

It’s an open-source CMS platform based on PHP, MySQL, and JavaScript. It has high-quality standards, good but complicated architecture, which allows customization of almost everything. It has, I would say, a big fan club of developers and the community, which has made significant contributions.

I have a couple of certifications and still think that it is the best CMS based on PHP, but to face the truth, it has its weak sides.

History

Let’s start with the history.

The first version of Magento was released in 2007, and it experienced rapid growth, becoming one of the popular e-commerce CMS platforms. It was based on the widely used Zend Framework of that time.

In 2015, Magento 2 was released. Under the hood, it used the same framework; however, the architecture concept was different, which made it impossible to do an easy migration, and basically, the migration was a full re-platforming (for the truth, there were migration scripts, but they worked badly and required a significant effort). That’s the first issue I explain in more detail below.

Key points in history.

In 2018, Adobe acquired Magento, promising developers and the community that nothing would change. But a lot has changed.

Issue #1. Migration.

Magento 1 was popular for all segments of the e-commerce market, ranging from small stores to big enterprises. The second version was released with a completely different architecture but still based on the same framework and with similar patterns and approaches.

Magento created some migrations for the database and even for the code, but, to put it mildly, they did not work well. The database migration script was improved over the years, but it still required experience to avoid pitfalls and execute the migration smoothly.

Everything was new, with only basic documentation. Developers learning Magento 2 had to figure it out through code and exploring how to write code correctly. I remember the first projects, and the quality of their code was far from ideal.

During the first two years, Magento 2 had numerous bugs and was not stable. The clients, who decided to switch to M2, faced a significant increase in estimates and bugs.

Issue #2. Entry barrier.

As I mentioned, Magento 2 has a very good and complex architecture that supports creating high-quality projects. But what happens if an agency with PHP developers sells Magento? Of course, they start developing without a proper understanding of architecture and M2 standards, leading to security and performance issues, and encountering unexpected bugs when they modify a class, thinking it will change behavior, but instead, it also alters another hidden (for them) functionality.

We had a lot of such clients with such terrible code. What did the client say?

We asked the Magento agency, and they quoted twice the cost of the other agency.

Ok, cool. Now the quote will be three times higher because we need to fix everything the previous agency did and implement everything properly.

Clients had to decide to pay more for qualified developers or take a chance with cheaper ones.

Issue #3. Frontend.

The architecture of the frontend allows for extending and modifying the UI without touching the original files. Developers can add blocks from any module, and it is easy to orchestrate with nested themes, etc. Such architecture allows for easy upgrades of Magento without a significant impact. For example, if a new feature is introduced with a new version, it will still work even if you have a fully customized frontend (assuming the developer develops everything properly according to standards).

But there are still some significant issues:

Deprecation. The original frontend is built using outdated technologies such as jQuery, Prototype, and Knockout.js.
Besides the standard frontend, there are some areas that use UI components—a way to build a dynamic frontend (like with React or Vue). However, the architecture of this solution is so complex that even experienced developers sometimes spend a lot of time implementing minor features. Of course, this approach affects the final costs.
Implementing good performance for the frontend requires effort, as does achieving a good score in Google PageSpeed Insights.
In 2018, Magento introduced PWA Studio — a way to build a headless solution based on React.js. But development dragged on, and developers reported a large number of bugs. Due to the rising popularity of PWA technology, many companies are building similar solutions: VueStorefront (now Alokai), ScandiPWA, etc.

Currently, another popular solution for Magento is Hyvä Theme, which allows building a frontend with the same flexibility and much better performance.

Issue #4. Adobe.

After Adobe acquired Magento, it rebranded it as Adobe Commerce and shifted focus toward large enterprise and B2B markets. They actively promote their Adobe Commerce Cloud and its services, which can be integrated into the Adobe Commerce ecosystem. They introduced numerous services that work with Adobe Commerce, such as Adobe Sensei, Live Search, and more.

The price of usage increased, and mentions of Open Source began to gradually fade.

Due to changing politics, many small and mid-market clients who initially migrated to Magento 2 have switched to less expensive platforms.

So where are all the stores now?

According to analytics from BuiltWith (https://trends.builtwith.com/shop), roughly 40% are built with Shopify.

We see that a lot of our clients migrate to another platform:

Shopify — I believe it is the most popular e-commerce solution today.
BigCommerce — another SaaS platform similar to Shopify.
A composable solution — a way to build only the frontend using popular frameworks like React or Vue, and all logic is orchestrated with various services (like CommerceTools, Algolia, Stripe, etc.).
Shopware — another solution with a similar stack (PHP and MySQL), that allows building also customizable web stores.

Very often, they refuse or simplify certain functionalities due to the limitations of SaaS solutions. However, from a business perspective, they gain many benefits such as low ownership costs, easier management, and improved store performance.

The approach to e-commerce on the web is shifting towards SaaS solutions, even platforms like Adobe Commerce and Shopware, which were initially open source, are now transitioning to a SaaS model. Is this the future? I believe so. Is it good? Well, I am an old-school developer, so I see it as a 50/50 situation — fewer ways to create something innovative and exciting, but better for business.

Conclusions

Would I still build projects based on Adobe Commerce or Magento? It depends. If the client needs to create a small fashion store, I don’t see any reason to complicate such a simple project — use Shopify. However, if the client requires complex and custom logic, B2B features, or the ability to scale, Adobe Commerce is the best solution, offering numerous opportunities for business growth.