Working at KATIM
Senior Security Engineer
I own SSDLC and security tooling at KATIM — the whole thing: program, tools, rollout, and vulnerability management.
SSDLC & Tooling
- Defining the SSDLC, planning the implementation, and getting developers to adopt it.
- Picked and integrated the security toolchain — Coverity, Checkmarx, Semgrep, Black Duck SCA — into the Jenkins pipelines and automated the security controls.
Vulnerability Platform
- Built a custom vulnerability-management tool that covers roughly 1,000 repositories.
- Consolidates six scanners across SAST, SCA and secret scanning, dedupes the findings, and runs AI-assisted triage on a local model for privacy.
AI in the Security Work
- Summarizing pull requests, generating custom security rules, and producing per-repo security profiles tuned to each project's characteristics.
Connections
- — Secure SDLC Program
- — Six-Scanner Triage Engine
- — FNZ · Accenture · Deloitte
- — Semgrep Rulesets
Previously
FNZ · Accenture · Deloitte
Five years of security work in Madrid before KATIM — from SOC operations to application security to leading a supply-chain initiative across an entire organization.
FNZ Group — Application Security Engineer
Oct 2023 – Jan 2025
- Built the automated security process in GitHub Actions for FNZ's wealth-platform clients: SAST on every pull request, secret scanning, dependency policy.
- Owned AppSec for ten-plus client tenants — pentest scheduling, security requirements, vendor selection — and led the supply-chain workstream.
Accenture — Security Delivery, Analyst → Senior
Oct 2020 – Oct 2023
- Led the software supply-chain security initiative across the organization and built its SLSA knowledge base.
- Managed three security teams of four to eight people: a client-embedded AppSec office, the internal DevSecOps lab, and the supply-chain initiative.
- Stayed hands-on: threat modeling, NIST and OWASP gap analyses, and security code reviews with custom rulesets per client.
Deloitte — Cybersecurity Operator
Feb – Oct 2020
- SOC operations: threat monitoring and incident triage across CrowdStrike, FireEye, Akamai, Splunk and Kibana, plus phishing analysis and end-user support.
Connections
- — Current Role
- — AppSec · 2023 – 25
- — Security Delivery · 2020 – 23
- — SOC · 2020
My Projects
Selected Builds
Things built around the day job, most of them scratching a real itch from it: tooling that removes friction, rules that catch real bugs, and this site.
Connections
- — This Website
- — Semgrep Rulesets
- — Local-Model Tooling
- — Six-Scanner Triage Engine
Blog
Writing & Notes
Notes from the field: turning scanner noise into shipped fixes, supply-chain integrity that survives contact with real pipelines, and what AI actually changes about application security.
Areas of Interest
Plus Toolstack
The threads I keep pulling on outside the ticket queue — and the tools I pull them with.
Connections
- — SLSA · Provenance
- — Agents · MCP · LLMs
- — Kubernetes · Containers
- — Scanners & Pipeline
4dlt.dev
This Website
This website. An Astro site with zero client frameworks — including this page: a hand-rolled force simulation after andrewtrousdale.com, a homepage prototype round, and a blog on the way.
Connections
- — Selected Builds
Custom Security Rules
Semgrep Rulesets
Custom static-analysis rulesets — Semgrep and friends — written per codebase when generic rules fall short, and lately generated with AI assistance at KATIM, tuned to each repo's security profile.
Connections
- — Selected Builds
- — Current Role
AI-Assisted Triage
Local-Model Tooling
Applying AI to security work where it genuinely helps: summarizing pull requests, generating custom security rules, and producing per-repo security profiles tuned to each project's characteristics — all on local models, for privacy.
Connections
- — Selected Builds
- — Agents · MCP · LLMs
Supply-Chain Security
SLSA · Provenance
From leading Accenture's supply-chain initiative — building its SLSA knowledge base — to FNZ's dependency policy to KATIM's SCA rollout: provenance, integrity, and knowing what is actually inside the build.
Connections
- — Plus Toolstack
AI × Security
Agents · MCP · LLMs
Where the field is going: AI-assisted triage, generated security rules, per-repo risk profiles — and the security of AI applications themselves, from MCP threat models to reviewing machine-written code.
Connections
- — Plus Toolstack
- — Local-Model Tooling
Cloud-Native Security
Kubernetes · Containers
Container and Kubernetes security: cluster hardening, runtime behavior, and supply-chain trust from image to admission — backed by the CCNSE and CCSE certifications.
Connections
- — Plus Toolstack
Toolstack
Scanners & Pipeline
Semgrep, Coverity, Checkmarx and Black Duck SCA for finding problems; Jenkins and GitHub Actions for the pipelines they live in; local LLMs for triage and rule generation.
Connections
- — Plus Toolstack
Álvaro De la Torre Ruiz
Senior Security Engineer
Most appsec programs ship dashboards full of findings nobody fixes. I build the platforms — and the developer programs — that turn scanner noise into shipped fixes.
- CCNSE — Certified Cloud-Native Security Expert, 2025
- CCSE — Certified Container Security Expert, Apr 2024
- CDE — Certified DevSecOps Expert, Jun 2023
- CDP — Certified DevSecOps Professional, May 2022
- PenTest+ — CompTIA PenTest+, Feb 2022
- Spanish — Native
- English — Professional
Writing & Notes
4 entries · notes from the field
Jun 14, 2026 · AppSec · 7 min read
Turning Scanner Noise into Shipped Fixes
Findings are free; fixes are expensive. Notes on making the economics work at a thousand repositories.
Every security team eventually learns the same lesson: a finding is not a fix. The scanner dashboard can show ten thousand findings and the codebase can be exactly as insecure as it was the day you bought the license. The metric that matters is mean-time-to-merged-fix, and almost nothing in the industry is designed around it.
At roughly a thousand repositories, triage stops being a meeting and becomes an engineering problem. We stopped asking whether a finding was real one ticket at a time and started asking what property of a finding class predicts that a developer will actually fix it. The answer was almost never severity. It was blast radius, proximity to code the team was already touching, and whether the fix was mechanical.
The uncomfortable part: most findings should be closed without a human ever reading them. Dedupe against the other five scanners, drop anything in dead code, drop anything below the app's actual trust boundary, and the queue shrinks by an order of magnitude. What remains is small enough to be owned — and ownership is what ships fixes.
The second uncomfortable part is that developers were never the bottleneck. The bottleneck was us — security — batching findings into quarterly reports instead of putting the right three into the pull request where the developer already was.
So the program now optimizes for one thing: the shortest possible path from detection to a diff. Everything else — dashboards, risk scores, steering committees — is overhead until that path is fast.
May 2, 2026 · Supply Chain · 9 min read
SLSA in the Real World
Provenance that survives contact with an actual Jenkins farm — what held up, and what didn't.
Provenance is easy on a slide and brutal in a Jenkins farm that grew organically for eight years. SLSA's levels read like a maturity model, but in practice they are a negotiation with every pipeline owner in the company.
The first honest step is inventory: you cannot attest what you cannot enumerate. We spent more time discovering builds than securing them — shadow pipelines, one-off release scripts, the Docker image somebody pushes from a laptop only in emergencies.
Level 1 is paperwork, Level 2 is plumbing, Level 3 is politics. Getting builds onto hardened, ephemeral runners means taking away the snowflake build machines people have quietly depended on for years, and no attestation format helps you with that conversation.
What actually survived contact: signed provenance generated inside the build and verified at admission — not in a report. The moment verification became a deploy gate instead of an audit artifact, provenance stopped being a compliance feature and started being an engineering control.
Would I do it again? Yes — but I would start with the verification gate and work backwards, instead of generating attestations for a year that nothing consumed.
Mar 21, 2026 · AI × Security · 6 min read
Local Models, Private Triage
Why our vulnerability triage runs on a box in the office instead of an API in another jurisdiction.
Our vulnerability triage runs on a workstation-class GPU in the office, not a hosted API. That decision gets questioned in every architecture review, and it keeps surviving for a boring reason: the input is our source code.
A triage prompt is not an abstract question. It carries the vulnerable function, its callers, the framework versions, sometimes the very secret that was committed. Shipping that context to a third party — any third party — creates exactly the data flow the rest of the security program exists to prevent.
The local model is dumber than the frontier ones. It hallucinates more and reasons worse. But triage turns out to be a forgiving task: the model proposes, a rules layer disposes, and anything low-confidence falls through to a human. We tuned the pipeline around the model's weaknesses instead of waiting for a smarter model.
The surprise was throughput economics. At a thousand repos, per-token pricing would have made continuous re-triage unaffordable; the local box makes marginal inference free, so we can afford to re-run everything on every scanner update.
Privacy was the reason we started. Cost is the reason we stayed.
Feb 8, 2026 · Platform · 5 min read
Six Scanners, One Truth
Deduplicating SAST, SCA and secrets findings into a single queue developers actually believe.
Every scanner vendor sells you a database of findings. Nobody sells you the join. The platform's real product is a single deduplicated queue that developers can trust — the six scanners behind it are an implementation detail.
Deduplication sounds like string matching and is actually identity design: what makes two findings the same across tools that disagree about file paths, line numbers, rule taxonomies, and even what a vulnerability is?
We ended up with a layered key — code location fuzzed against git history, then rule-class equivalence maps, then a semantic pass for the stragglers. Each layer is dumb; the stack is accurate enough that developers stopped seeing duplicates, which is the only benchmark that matters.
The unexpected dividend: once findings had stable identities, everything downstream got easier. Suppressions survived rescans, metrics stopped double counting, and AI triage could accumulate history per finding instead of starting cold on every scan.