Vikram Malkan

Supply-chain build pipeline: SBOM, signing, scan gating

Irulast / Guilding For The Folks · shared CI platform Broken images fail in CI now instead of in production, and everything that runs is signed and inventoried.

Images passed CI and then would not run. The build checked one thing and the registry checked another, and the only symptom was an ImagePullBackOff in production.

• Every image goes through a pipeline that produces a CycloneDX SBOM, signs the image with cosign using a short-lived OIDC token, and runs a Trivy scan that fails the build on critical findings.
• Found why broken images were getting through. The scanner was set to ignore OS package findings before applying the critical gate, so CI only graded application dependencies while the registry graded the OS too and refused the pull. Changed the build gate to match the registry gate, so the build fails first, where it is cheap to fix.
• Pinned base images by digest instead of tag. A floating tag had moved on its own to a new distribution release with new CVEs, with no commit in the repo, and the first sign of it was a production pull failure. Updating a base image is now a commit someone reviews.
• Picked base images by their actual vulnerability counts instead of habit, and wrote the comparison into the Dockerfile so the next person does not change it back to a worse one.

Every image is signed, inventoried, and scanned before it can run, and problems show up at build time instead of deploy time.

• CycloneDX SBOM
• cosign / OIDC
• Trivy
• Supply chain
• GitHub Actions
• BuildKit

Network segmentation, isolation testing & the security program

Irulast · leading ISO 27001 / SOC 2 readiness One compromised workstation can no longer reach every server in the building, and I proved it by attacking the guest network myself.

A flat /16 where one compromised workstation could reach every server, hypervisor, and switch management interface in the building. On top of that, a certification goal that turns every informal control into something that has to be written down and shown to someone outside the company.

• Designed the replacement: 13 VLANs split by security zone — admin workstations, office clients, servers, Kubernetes and BGP nodes, hypervisor management, cluster storage, printers and IoT, guest, public DMZ, backup, monitoring, network management, and out-of-band hardware management. pfSense is the only device allowed to route between them, so every crossing between zones can be filtered and logged.
• Rewired the physical cabling and migrated the switches port by port — VLAN database, trunk and access port assignments, firewall rules for each zone, and admin access moved behind WireGuard instead of an SSH port forwarded from the WAN.
• Tested the guest network's isolation by attacking it: wireless survey to confirm which SSIDs were in scope, host discovery on the guest subnet, a top-100 port sweep, targeted TCP probes against anything that answered, then sweeps toward the internal ranges to prove the guest segment could not reach them. Added manual probes where the scanner's result was ambiguous.
• Kept the raw scan output, staged by phase, so the result can be run again and checked instead of taken on my word.
• Leading the work toward ISO 27001 and SOC 2, control by control rather than starting with paperwork: central identity behind an SSH certificate authority, per-tenant secret isolation that fails closed, least-privilege Kubernetes access, image provenance policy, a hardening baseline for machines with no MDM, a risk register for the physical security systems, and the asset inventory the rest of it gets checked against. No auditor engaged yet.
• Used the same boundary rules inside the Kubernetes cluster: deny by default, service accounts scoped to one namespace per tenant, and mutual TLS for identity instead of trusting IP addresses.

Segmentation that has been tested from the outside instead of assumed, and a set of controls being built so they can be shown to an auditor rather than described.

• Network segmentation
• pfSense / VLANs
• Isolation testing
• nmap
• ISO 27001 / SOC 2 readiness
• Risk register
• Zero trust / mTLS
• Evidence collection

Fleet hardening, identity & per-tenant secret isolation

Irulast · bare-metal Kubernetes platform SSH password auth was on where the playbook said it was off. Now the boundaries are checked against the machines, and a tenant’s secrets only open for that tenant.

The gap between what the configuration says and what the machines are actually doing. On a fleet built from cloud-init images, provisioned with Ansible, and rented out to other organizations, that gap is where problems start.

• Found password authentication turned on for SSH on a machine that was supposed to have it off. The provisioning playbook sets PasswordAuthentication no in sshd_config, but cloud-init images ship a drop-in file under sshd_config.d/ that sets it back to yes. The include line sits at the top of sshd_config and sshd keeps the first value it reads, so the drop-in won. It had been that way since the machine was built, and the installer's temporary password account was still on it. Fixed the playbook to overwrite the drop-in so new machines get the value they are supposed to have, and wrote a separate playbook to fix the machines that were already built.
• Ran central identity for the fleet on LDAP with an OpenBao SSH certificate authority. One edge node outside the cluster VLAN skips central identity on purpose, so I gave its local accounts the same UID and GID they have in LDAP, so adding it to central identity later will not collide with the accounts already on it.
• Built per-tenant secret isolation in OpenBao: a key-value mount for each tenant, a read-only policy bound to that tenant's External Secrets role, and an admin policy that gives the tenant's own login group control of its own mount. Tenants manage their own secrets instead of asking us to load them, and if the binding breaks the secrets stop resolving rather than falling back to something more open.
• Fixed that exact failure for two tenants. OpenBao was rejecting the External Secrets login because the role name it was using had never been created, so every secret in those namespaces was stuck. Checked the role names, mount paths, and service account names against each tenant's own manifests before writing the fix.
• Kept access narrow: workload identities scoped to a single namespace, read-only Kubernetes access for checks that do not need to write, and an admission policy that verifies an image was actually built by the organization it claims to come from.

Boundaries I have checked against the running machines, instead of assuming they are there because the playbook that was supposed to create them finished without an error.

• OpenBao / Vault
• External Secrets
• SSH certificate authority
• LDAP identity
• Ansible hardening
• Kyverno admission policy
• Kubernetes RBAC
• Multi-tenancy

Multi-chain RPC gateway — onboarding Bitcoin as a second chain

Irulast · iriga platform · Rust Bitcoin runs next to Chia in one gateway, so tenant applications get chain data without ever holding node credentials.

The platform's caching RPC gateway only spoke to Chia. Adding Bitcoin meant a second chain with a different request format, different rules about what can be cached, and different failure modes — without splitting the gateway in two or making the cache aware of which chain it was handling.

• Added Bitcoin as the platform's second chain end to end — node agent plugin and chain-type dispatch, controller environment setup, the gateway plugin, deployment manifests, and snapshot bootstrap — as a series of pull requests against a written spec.
• Wrote the adapter that handles the two request formats. Chia clients send POST /{endpoint}. bitcoind takes a single POST / with the method inside a JSON-RPC body. Both get converted into the same (endpoint, params) pair, so the cache key, the method allow-list, and the metrics underneath never need to know which chain they are serving.
• Cached in Redis, keyed by chain rather than by node, with three classes of data. Results that never change once confirmed are cached indefinitely. Results that are only valid at the current block height have the height built into the key, so a new block makes the old entries unreachable and nothing has to go clean them up. Writes are never cached and clear the keys they affect.
• Kept tenant applications off the node itself. They call the gateway and never hold node credentials, methods outside the allow-list are rejected instead of forwarded, and the node's RPC port is not reachable directly.
• Added an alert for a node that reports itself synced but has not moved its block height in 60 minutes, which is what a stalled node looks like from the outside.
• Fixed the reliability problems that came up after: retries against a stale authentication cookie, a corrupt bitcoind settings file that had to be repaired before start, respawn logic that restarted the process without checking it first, and auto-heal that measured how far behind a node was against the snapshot it started from instead of the current fleet tip.

One gateway serving two chains with one cache and one set of policies. Another team's application uses it to confirm game outcomes on chain. I built the gateway and the node lifecycle, not the contracts on top of it.

• Rust
• JSON-RPC
• Redis / cache invalidation
• Kubernetes controllers
• Prometheus / Alertmanager
• Bitcoin Core
• Spec-driven delivery

Bare-metal Kubernetes platform & GitOps

Irulast · ~100 of my commits Other people deploy onto hardware we own, safely, with the rules written down in Git instead of remembered.

Running a multi-tenant platform on hardware we own, where every credential, deployment, and boundary has to be set up on purpose because there is no cloud provider doing it by default.

• Provisioned and maintained the cluster with Ansible and GitOps. The repository holds the desired state and Flux corrects anything that drifts away from it.
• Added a Dell R720 and a Raspberry Pi 4 to the fleet — provisioned, joined, and added to the CI/CD pipeline. The Pi runs as an edge node outside the cluster VLAN, so the bootstrap had to work on a machine that cannot reach in-fleet services, and the fleet now runs two architectures instead of one.
• Onboarded outside organizations onto the platform: namespace and registry project, secret mounts and identity, their own build runner, GitOps image automation, and the admission policy that checks their images. A tenant shows up with a repository and ends up with a running application.
• Kept secrets out of Git. A secrets manager backs the external secret references, registry robot accounts are scoped to one project each, and CI logs in with short-lived OIDC tokens instead of stored credentials. There are no registry credentials in any workflow file.
• Contributed to the tenant control plane at platform.irulast.com, a Rust API and React front end that shows tenants their own services, pod health, node status, and logs, plus the onboarding steps. Login goes through Keycloak on the backend, so the browser never holds a token, and the tenant's scope is set by the server instead of sent by the client. The portal stays read-only on purpose — it checks onboarding steps but never performs a privileged action, so self-service secrets live in OpenBao where the tenant's own group authorizes it.
• Ran Keycloak as the identity provider with OIDC group-to-role mapping, and PostgreSQL under an operator for the platform's stateful services.
• Automated the repeating work — scheduled cache cleanup with tiered pruning, image refresh, and snapshot retention — so nobody has to remember to do it.
• Wrote a Kubernetes controller in Rust with custom resource definitions, including scheduling that spreads a workload's nodes across different physical hosts.
• Put Cloudflare DNS and Tunnels in front of the platform, with cloud capacity available when the local hardware is not enough.
• Documented it: architecture guides, migration plans, deployment order, and decision records explaining why the important choices are what they are. Also stood up the internal documentation site itself, from the initial scaffold through a hardened nginx image, release CI, and GitOps delivery behind the internal gateway.

A platform other people can deploy onto safely, with the security rules written down instead of remembered.

• Linux
• Ansible
• Kubernetes / Flux
• PostgreSQL
• Keycloak / OIDC
• Secrets management
• Rust
• Cloudflare
• Grafana

Asset inventory reconciliation

Irulast · NetBox source of truth Security questions get answered off the inventory now instead of a walk to the rack.

The inventory system said one thing and the racks said another. Every security question after that — what is running, where it is, what firmware it has — inherits the same error.

• Ran a series of audits against NetBox as the source of truth: site records, device hardware inventory, storage locations, locker contents, and a rack consolidation. Each one was written up before I ran it, so it can be run again the same way.
• Generated health reports for every drive we own from SMART data, which gave the inventory condition information it did not have before.
• Compared the records against what is physically there and pushed the differences — missing records, wrong locations, stale entries — back into NetBox.

An inventory I can use as an input to security decisions instead of one that has to be re-checked by hand every time it matters.

• Data quality
• Reconciliation
• NetBox / IPAM
• Reporting
• SMART / hardware

One Mac to rebuild and put under management, with the platform question arriving already framed as Jamf versus Intune. Both were the wrong shape, and the ground under the question had moved four months earlier.

• Wrote six pass/fail requirements out of the contract language rather than off a feature comparison, so a platform that missed one was excluded no matter how well it scored elsewhere.
• Ruled out Intune on architecture, not features. Its macOS support is genuinely good now — shell scripts, declarative device management, Platform SSO. It also needs the Entra ID tenant that the same engagement is contracted to take apart, so choosing it would have meant keeping the thing we were paid to remove.
• Found that Apple Business Manager — free since April 2026, and the reason most Apple-management advice written before then is now wrong — is not a competitor to the paid platforms but the layer they all sit on. It covers supervised enrollment, FileVault escrow and enforced macOS updates, but not third-party patching or vulnerability reporting, which is the exact clause the contract promises. Free alone could not deliver it.
• Priced every option at the device count that actually applies. Addigy is the best-architected of them for managing clients, but its floor is per Addigy account rather than per client, so it only breaks even at around 32 Macs. This job has one. Jamf Pro has a 25-device minimum for the same reason.
• Recommended Apple Business Manager plus Mosyle, the cheapest platform clearing all six requirements, at $360 a year against $2,400. Wrote down what would change the answer — a Mac practice, a compliance obligation, EDR entering scope — so the next person can tell whether the decision still holds instead of redoing the evaluation.
• Flagged a commercial problem that was not mine to solve but was mine to raise: a vendor minimum passed through as a per-device cost has one client funding capacity other clients use.
• Rewrote what the client actually receives. A nineteen-question intake form hands our discovery work to someone who cannot do it, so it became four questions and a call we drive, with everything else determined from access we ask for. Decisions go to the client as recommendations, not questions.
• Wrote the rebuild runbook, the provenance record filled in before anything is erased, and a test plan to prove the platform on a spare machine before it touches the client's.

A recommendation with its reasoning written down, and the runbooks waiting on it. The decision belongs to the engagement lead and had not been made when this was written.

• macOS management
• MDM evaluation
• Apple Business Manager / ADE
• Decision records
• Vendor assessment
• Requirements from contract
• Client delivery
• Runbooks

A contract manufacturer inherits a quality system along with the company. It then has to hold up to an FDA inspection, third-party audits, and every new customer who shows up with a product and no manufacturing process to build it by.

• Owned the QMS under ISO 13485 and FDA 21 CFR Part 820 — document control, CAPA, nonconformance, complaints, internal audits, supplier qualification, and training records. The system was already there when I got it and I built it out from there.
• Wrote over 60 of the organization's controlled documents. My name is in the change log or the approval signatures on close to all of the rest.
• Wrote the full documentation set from scratch for our own product, a calcium hydroxylapatite subdermal filler.
• Onboarded two new customer products from start to finish while maintaining a third. Worked out the manufacturing process, wrote the requirements, procedures, and work instructions, then ran the process by hand with the customer's team to prove it worked before releasing it to production.
• Took part in an FDA inspection and third-party audits. The FDA inspection closed with no findings. What the auditor did point out was wording, formatting, and references pointing at documents that had been replaced, which is a document control problem and got handled as one.

Rebuilt the manufacturing process for a vaccine product we build under contract, focused on the assembly and sterilization steps where the losses actually were. Dunnage went from around 1,000 units per 6,000-unit lot — about a fifth of it from improper assembly against a work instruction that was not detailed enough — down to around 10.

• ISO 13485
• FDA 21 CFR Part 820
• Class III device
• CAPA / nonconformance
• Document control
• Process development
• Supplier qualification
• Audit readiness

Compliance gap analysis is slow, and the easy way to speed it up with a language model is also the way to get confidently wrong answers into an audit record.

• Built a tool that checks a set of documents against a versioned clause library and produces a report marking every requirement COVERED, PARTIAL, MISSING, NO_EVIDENCE, or NEEDS_CLARIFICATION.
• Made the evidence rule something the tool enforces instead of something the model is asked to do. A COVERED result without a citation that resolves is rejected and cannot be saved.
• Every output is a draft for a person to review. Nothing approves itself. AI output is a lead to check, not evidence.
• Credentials stay on the server and never reach the browser or the repository.

Faster gap analysis without the failure that makes AI-assisted compliance work useless — a "compliant" answer nobody can trace back to a source.

• Requirements management
• ISO 13485
• Traceability
• AI output validation
• Python / Flask
• Docker

Teams arrange practice matches by hand across Discord, and the part that actually breaks is the server. Two teams agree a time and then have to work out who is providing somewhere to play.

• Built sign-in on Steam and account linking to RGL, the league, so a team's roster, format and division come from the league instead of being retyped and going stale.
• Reads three third-party APIs — RGL, logs.tf and trends.tf — none of which needs a credential. All three are cached locally and every page renders from the store, so an upstream that is slow or down shows older data rather than a spinner. Uploading logs is deliberately out of scope, which is what lets that whole feature hold no secret at all.
• Gave teams two free ways to get a server: paste their own connect line onto the scrim, or link a serveme account and reserve one from the scrim's page. The site does not host game servers.
• Parked the paid hosting instead of shipping it. The original design assumed a Kubernetes workload per game server, and that assumption is what stopped it. I replaced it with a pool of registered Docker hosts and took that as far as code goes — but a pool needs machines with public game ports, and answering "where should these actually run" is worth more than shipping half of it. The paid path is off behind one flag, not deleted: the pool, the reconciler, the ledger and their tests all still pass.
• Wrote each feature to a spec before building it — 14 numbered specs with the decision records next to them, so the reason something is the shape it is outlives my memory of it.

A scrim surface that costs nothing to use, and a paid path that is one configuration value away if the hosting question ever gets a real answer.

• Python / Flask
• PostgreSQL
• Steam OAuth
• Third-party APIs
• Spec-driven delivery
• Decision records
• Docker

The fastest way to find out whether a platform is actually usable is to be a tenant of it rather than an operator of it, and to pay the same costs everyone else pays.

• Put four of my own things through it: this site, the TF2 platform, a K-pop companion site (janvi.net), and a personal workstation that runs on the cluster and is reachable only over Tailscale — so my laptop stops being where the disk and the CPU have to live.
• Ran every one of them through the same gates every other tenant gets — SBOM, signature, a scan that fails the build, base image pinned by digest, non-root with a read-only root filesystem. No exceptions for my own work, which is the only way to find out whether the gates are actually workable.
• Kept deployed state in its own repository, so what is running is a file somebody can read rather than something applied by hand, and let the image automation write each new tag back to Git after the build.
• Wrote down what actually bites, because I hit it: a missing pull secret reads like a bad image tag, a runner label that matches nothing queues forever with no error at all, and a scanner set to skip OS packages grades less than the registry does and lets a broken image through.

Four applications on the platform under the same rules as anyone else, and a list of the failures that look like something other than what they are — written from the tenant side, where they are confusing.

• Kubernetes
• Flux / GitOps
• Harbor
• Supply chain
• Tailscale
• Multi-tenancy

OT security advice is easy to give from a slide and harder to give from a bench. Time on real industrial hardware is the part most people skip.

• DEF CON 2026, ICS Village. The hardware showed up unconfigured, so I programmed the Rockwell PLCs in Studio 5000 and set up the tower lights, HMI, and ControlNet hardware into a working lab. Players connected over the village network and found flags by navigating CIP. I also wrote a couple of the flags. The contest itself — scoring, accounts, and flag infrastructure in CTFd — was Trevor's build.
• Marquette University IoT CTF. Aaron Wasserman built the board. My job was to break it before the students did. I worked the whole lab start to finish to make sure the student write-up actually led somewhere, fixed the bugs I found, gave input on the challenges, and wrote scripts to check flag answers, run the lab to completion, and dump the firmware over UART to see whether what came back was a real image.
• Modbus SCADA lab — simulated building management, cooling, and power monitoring devices behind an Ignition gateway. Scanning for TCP/502, enumerating registers, and a replay write against a live SCADA system, then the mitigations for it. Neil Brandon built the lab. I organized the summit and took it as a participant.
• National Cyber League — coached students through the season. Found challenges, worked them myself first, then recorded walkthroughs so students could follow the solution instead of being handed it.

Enough hands-on time to know why protocols with no authentication put the weight on segmentation and monitoring — and a clear line between what I built and what I only used.

• Rockwell / Studio 5000
• CIP / EtherNet/IP
• ControlNet
• PLC / HMI
• Modbus / SCADA
• UART / firmware extraction
• CTF development

xftf.org — moving the community off a hosted platform

Security For The Folks · Flask on Kubernetes The community owns its site and its posts now, and a copy change is one edit instead of a hosted product’s module.

The community site ran on Odoo, so the shape of the site was whatever that product's modules happened to be, and every post lived in someone else's database.

• Migrated it off Odoo. Carried the content, the images and the URL paths across so existing links kept working, and left the theme and the module furniture — /shop, /forum, /jobs, /slides — behind.
• Built a real blog for the community. Anyone who registers can publish immediately — no approval queue, by decision — with the counterweights placed after the fact rather than in front of the person writing.
• Let people write in Markdown or upload straight out of an Obsidian vault, and render it through a sanitizer. Allowing anyone to publish is a different decision from allowing anyone to publish HTML, and only one of them was made.
• Kept the site copy in Python rather than in the templates, so changing a conference blurb or adding a crew member is an edit to one list and the templates stay presentation-only.
• Gave the summit its own microsite inside the same application, with its own chrome instead of the site's.
• Postgres with migrations applied at startup, containerized with the base pinned by digest, and deployed to the cluster by Flux — the same path everything else of mine takes.

xftf.org runs on infrastructure the community controls. Blog posts are rows in Postgres, written through the site and never committed; everything else is a one-line edit and a deploy.

• Python / Flask
• PostgreSQL / Alembic
• Platform migration
• Markdown / sanitization
• Kubernetes / Flux
• Community tooling

Security For The Folks — founding an OT security community

Founder · xftf.org 100+ OT security people have a place to meet, and a summit that manufacturers, the FBI, vendors, and a university all show up to.

Manufacturing, government, and academic security people in the same region dealing with the same OT threats, with no shared place to meet.

• Founded and run a 100+ member OT security community. We meet weekly across Zoom, Discord, and Slack to plan events and keep people involved.
• Founded and organize the Midwest OT Cybersecurity Summit (MOCS), midwest-otcs.org. I run the program and call for speakers, the venue, sponsor recruiting, and logistics, and I gave the opening keynote. MOCS 2026 brought in over 100 attendees from seven states.
• Built the partnerships the event runs on. Marquette University's Center for Cyber Security co-organizes it and provides the venue. Malkan Solutions, AWS, IBM Consulting, and the Northwestern Mutual Data Science Institute are title sponsors, and Rockwell Automation, Claroty, FBI Milwaukee, Johnson Controls, and the ICS Village are sponsors and partners. MOCS 2027 runs April 16 at Marquette's AMU ballroom, with about 12 sessions across three rooms.
• Represent the community as one of the outside practitioners brought into Marquette's intro cybersecurity course, so the 40+ students in it hear from people doing the work and not only from the syllabus.
• Built and run the community platform. It started as Odoo on AWS and moved through SQLite and MongoDB to Postgres as the group grew. In August 2026 I replaced it outright with a Flask application on Kubernetes, which is the xftf.org card.

A regular place for industrial security people in the region to talk to each other, and a conference that manufacturers, the FBI, vendors, and a university all show up to.

• Community leadership
• Conference organizing
• Public speaking
• Sponsor & partner development
• OT threat landscape
• Python / Flask
• AWS
• Database migration