DEV Community: Rostyslav Myronenko

Why Checkov catches the WHAT but not the WHY

Rostyslav Myronenko — Tue, 14 Apr 2026 07:30:00 +0000

Checkov is excellent. I use it. You should use it. This article is not an attack on Checkov.

But there's a specific class of infrastructure risk that Checkov - and every rule-based IaC linter - structurally cannot catch. Understanding the difference changes how you think about infrastructure reviews.

Let's call it the WHAT vs WHY problem.

What rule-based linters do

Checkov, Trivy, tfsec, KICS - all of them operate on the same principle: encode a known-bad pattern as a rule, flag any resource that matches the pattern.

This is powerful. It's also inherently scoped to individual resources.

A rule that says "RDS instances should have Multi-AZ enabled" looks at a single 'aws_db_instance' block. It doesn't know what depends on that database. It doesn't know what your SLA commitment is. It doesn't know that the Lambda function reading from it handles payment webhooks.

The rule catches the WHAT: Multi-AZ is disabled.

It can't catch the WHY: that this specific database going down takes out your entire revenue pipeline.

An example: the clean Checkov output problem

Here's a real pattern I see in Terraform codebases:

S3 bucket: logging disabled → Checkov flags it ✓
IAM role: wildcard action on that S3 bucket → Checkov flags it ✓
Lambda: reads from the bucket + writes to RDS → not flagged
RDS: Multi-AZ disabled, no automated backups enabled → Checkov flags both ✓

Checkov catches four individual issues. What it doesn't catch: that these four issues together create a system where a compromised Lambda can exfiltrate the entire data tier, and if the RDS instance fails during the exfiltration, there's no backup and no audit trail.

This isn't four separate findings. It's one architecture finding: your data tier has no defence in depth.

Rule-based tools report each flag independently. They have no model of how resources relate to each other.

What architecture reasoning adds

The AWS Well-Architected Framework is the closest thing the industry has to a structured architecture reasoning system. Its five pillars — Security, Reliability, Performance Efficiency, Cost Optimization, Operational Excellence - are explicitly about systems-level thinking, not individual resource configuration.

When a senior engineer reviews Terraform, they're not running through a checklist. They're asking:

What is the blast radius if this component fails?
What does the audit trail look like under a security incident?
Where are the single points of failure?
What happens at 10x current load?

These questions require knowing how components relate to each other — which is precisely what a rule engine cannot do.

The gap in practice

In real infrastructure reviews, the conversation that matters is almost never about the flagged resource. It's about what the flagged resource connects to.

"Your S3 bucket logging is disabled" is the start of the conversation, not the finding.

The finding is: "Your S3 bucket is the source of truth for your data pipeline, logging is disabled, and there's no alternative audit trail — which means a data breach would be undetectable until a customer reported missing data."

That's architecture reasoning. It requires:

Knowing what the S3 bucket does in context (not just its configuration)
Understanding the downstream impact (the pipeline, the data classification, the SLA)
Synthesising multiple resource attributes into a single architectural narrative

This is the analysis a senior DevOps engineer runs through in their head. It's not in any rule file.

How ArchGuard approaches this

ArchGuard takes your Terraform code and a brief description of your workload, then generates structured findings across all four AWS Well-Architected pillars using architectural reasoning — not rule matching.

Each finding has three parts:

Evidence: the specific resource, attribute, and value
Why: the architectural impact - what breaks, what's at risk, at what scale
Recommendation: a concrete action, not a link to the docs

This is complementary to Checkov, not a replacement. Run your linter first. Checkov will catch the configuration issues efficiently, at scale, for free. Then run ArchGuard to understand what those findings mean in the context of your architecture.

WHAT → Checkov. WHY → ArchGuard.

Try it

ArchGuard is in early access at archguard.io. Free during beta. You share your Terraform, describe your workload, and get a structured findings report back.

If you run infrastructure reviews for clients — or you've inherited an AWS environment and want to understand what you're actually looking at — I'd genuinely like your feedback.

What's actually inside an EU AI Act Annex IV technical file (and what engineers usually miss)

Rostyslav Myronenko — Tue, 07 Apr 2026 09:06:48 +0000

If you're building a high-risk AI system for the EU market, you'll eventually need to produce an Annex IV Technical File. Most engineers have no idea what's in it until someone from legal drops a deadline on their desk.

Here's what it actually contains, what you need to build, and where teams consistently fall short.

What is the Annex IV Technical File?

It's the mandatory documentation package that high-risk AI system providers must compile before placing their system on the EU market. Think of it as the technical dossier a notified body or national authority would review if they came knocking.

It's defined in Article 11 of the EU AI Act, with the full list of required contents in Annex IV.

Who needs it? Providers of high-risk AI systems under Annex III (employment screening, credit scoring, biometric identification, critical infrastructure, etc.) and systems integrated as safety components of regulated products under Annex I (medical devices, machinery, etc.).

Deployers don't need to build one - but you should ask your provider for it. If they can't hand one over, that's a red flag.

What It Must Contain

The Technical File isn't a single document - it's a collection of artifacts across 9 areas:

1. General description + intended purpose

What the system does, what it's designed for, and what it's explicitly not designed for
The categories of people it affects
Input data types and outputs

2. Development process and design choices

System architecture (with diagrams)
Key design decisions and their rationale
If it uses third-party components (models, datasets, libraries) - document them

3. Risk management system (Article 9)

This is the one that trips teams up most. Risk management under the AI Act is not a one-time checklist. It must be:

A continuous process throughout the lifecycle
Documented with identified risks, mitigation measures, and residual risk assessments
Updated when the system changes or new risks emerge

4. Data governance (Article 10)

Description of training, validation, and test datasets
Data collection and labelling methodology
Known limitations and potential biases in the data
Measures taken to detect and correct issues

This needs to describe what actually happened, not what you intended to do. Auditors know the difference.

5. System architecture and technical specifications

Detailed architecture documentation
Hardware requirements
Integration points and APIs
Performance benchmarks

6. Monitoring, logging, and audit trails (Article 12)

The system must automatically log events "to the extent appropriate to the intended purpose." Logs must be:

Sufficient to identify the start/end of each use session
Tamper-evident (immutable or access-controlled)
Retained for appropriate periods

Common gap: Teams have application logs but no AI-specific audit trail. "It's all in CloudWatch" isn't sufficient if you can't reconstruct what input produced what output for a given user at a given time.

7. Information for deployers (Article 13 — transparency)

Intended use and conditions of use
Performance characteristics and limitations
Human oversight requirements
Pre-processing requirements for input data
What the system cannot do (this is mandatory, not optional)

8. Human oversight measures (Article 14)

What oversight mechanisms are built into the system
How a human can intervene, override, or halt the system
Who is responsible for oversight and what training they need

9. Accuracy, robustness, and cybersecurity (Article 15)

Declared accuracy metrics (and what they mean)
Performance across different groups or subpopulations
Resilience against errors, faults, and adversarial inputs
Cybersecurity measures

Plus: You'll also need:

Conformity assessment results (where applicable)
EU declaration of conformity (Article 47)
Post-market monitoring plan (Article 72)

The Gaps Teams Consistently Miss

After reviewing how teams approach this, a few gaps come up again and again:

1. Risk management as a checkbox, not a process
Teams write a risk assessment doc once, mark it done, and move on. The regulation explicitly requires it to be a continuous process. Your Technical File needs to show it's maintained.

2. No immutable audit logs
Application logs exist, but they're not tamper-evident and they don't capture what the AI system specifically decided. This is one of the harder technical gaps to retrofit.

3. Data governance docs describe intent, not reality
"We used a balanced, representative dataset" without specifics doesn't pass scrutiny. You need actual methodology, known limitations, and bias mitigation measures documented.

4. Missing post-market monitoring plan
This is often the last thing teams think about. The AI Act requires it before deployment, not after. At minimum: what metrics you'll track, thresholds that trigger re-evaluation, and who's responsible.

5. No "information for deployers" document
If you sell to businesses, they need documentation about how to use your system within its intended purpose. This is a separate deliverable from your internal technical docs.

Where to Start

The Technical File sounds daunting but it's mostly about having the right process in place from the start, not retrofitting it at the end.

Before writing docs, identify which gaps actually exist in your system. There's a free tool that maps your current artifacts against each Annex IV pillar and tells you what's missing: aiactgap.com - no login, no data stored, downloadable PDF report.

The August 2026 deadline is when enforcement kicks in for existing high-risk systems. That's less time than it sounds when you factor in the documentation effort.

TL;DR

Annex IV Technical File = mandatory for high-risk AI providers before EU market placement
It spans 9 areas from architecture to post-market monitoring
Risk management must be continuous, not a one-time doc
Audit logs need to be AI-specific and tamper-evident
The most-missed item: the post-market monitoring plan
Deadline: August 2, 2026 for existing systems

Built aiactgap.com - a free EU AI Act gap checker that tells you which Annex IV artifacts you're missing. Happy to answer questions in the comments.