Know what you're running. Know what to fix first.
Since 2011 we've been working inside other people's Rails codebases, and infrastructure is usually where the surprises are. We read your registry, clusters, CI history, and repos, cross-reference every image against CISA's Known Exploited Vulnerabilities catalogue, and hand you a prioritized plan. Four to six weeks, fixed scope, read-only access.
Authors of The Complete Guide to Upgrade Rails, free since 2018.
- 100%
- of the known-exploited CVEs we found were past their CISA remediation deadline
- 9 in 10
- production images carrying at least one critical CVE
- Half
- the fleet running images never rebuilt after their base image was patched
- Most
- of those vulnerabilities came from system packages, not from application code
Anonymized findings from a real engagement across a multi-cluster estate with hundreds of deployments.
The patch that never reaches production
A patched base image only helps once the applications on top of it are rebuilt. That's usually automated, but we still find registries where it isn't, and the fix sits there for months without shipping.
A scan is not a plan
Scan a mid-size setup and you get back hundreds of thousands of CVEs. Without severity, exploitability, and environment context, nobody can act on that.
Nobody owns the whole picture
Runtime versions, OS support windows, deploy history, and database versions live in four different systems. No single view tells you what is running where.
Nine layers of your infrastructure, one report
Read-only access is enough. We work from your registry, clusters, CI history, and repositories. Nothing to install, and no changes to production.
Container image security
How the registry is organized, whether tagging is disciplined, how stale each image is against its last base rebuild, and a full CVE scan by severity and environment.
CISA KEV exposure
Every image cross-referenced against the Known Exploited Vulnerabilities catalogue, with the remediation deadlines you've already missed and the packages driving the count.
Operating system health
Every distro and version mapped to its support timeline, so you know which deployments are past security support and by how long.
Runtime & framework EOL
Ruby, Rails, Node, npm, Yarn, Python, Java, and PHP. Version distribution per environment, checked against published end-of-life dates.
Dependency debt
Libyear analysis across your whole portfolio, rating each app from good to critical, so upgrade sequencing comes from evidence instead of instinct.
Kubernetes workload configuration
Manifests left on defaults, containers running as root that don't need to, missing security contexts and network policies, and resource limits nobody ever set.
Database & storage
Engine versions and support dates, persistence and access modes, reclaim policies, and volumes provisioned inconsistently across environments.
Pipeline & deploy history
Promotion gates, environment drift, secret and config management, plus the CI history that surfaces broken pipelines and apps that have never been deployed to production at all.
Cost & provisioning
Where storage and compute are over or under provisioned, and which idle or abandoned environments you are still paying for every month.
Full inventories, appended
Every finding is backed by a per-application appendix, so your team can work straight from the data instead of re-deriving it.
A 30-60-90 day plan, ordered by what actually reduces risk
Findings are only half of it. Every assessment closes with a prioritized list your team can start on the day it lands. Below is how one of those plans came out. Yours gets ordered by what your own infrastructure turns up.
- Upgrade EOL databases that are still serving production traffic.
- Rebuild the images that have drifted behind an already-patched base, worst critical counts in production first.
- Retire EOL operating systems as part of that same rebuild.
- Remediate KEV exposure, starting with whatever clears the most images at once.
- Upgrade EOL frameworks, worst dependency debt first.
- Scope the deprecated tooling migrations that need application-level changes.
- Upgrade the runtimes already past end of life, starting wherever they are serving production traffic.
- Set workload defaults deliberately: security contexts, network policies, and resource limits, applied by policy instead of per manifest.
- Require every release to pass through pre-production before it can reach production.
- Make image scanning a build gate so exposure gets caught before it ships.
- Automate dependency updates so the work you just did holds.
- Right-size storage and compute where environments have drifted apart.
An anonymized plan from a real engagement, kept here as an example of the shape. The tiers hold, the contents change with what we find.
An assessment tells you what's exposed. It won't tell you whether someone can actually get in.
Those are two different questions, and the second one needs somebody actively trying. We scope that work separately from the assessment, because it needs a narrower target and a different kind of permission.
Penetration testing
A defined target, a defined window, and a written report of what we got into and how we did it.
Red team exercises
We work toward an objective the way an attacker would, so you find out whether your detection and response actually fire.
CVE validation and VEX
A scanner says you're exposed to a given CVE. We tell you whether it's actually reachable in your configuration, and write the verdict up as VEX so the ones that don't affect you stay suppressed everywhere, in every scan after this one.
Bug hunting
Time-boxed adversarial review of one application or service, looking for the things a scanner will never surface.
Scope and limits. Always authorized in writing, and always against targets you own. We don't build command-and-control infrastructure, run mass data exfiltration, or develop ransomware, and we'll turn down work that starts heading that way.
Not sure which of these you need? Mention it in the form below and we'll tell you. Sometimes the honest answer is that the read-only assessment is already enough.
Your team could do this themselves
We're not going to pretend otherwise. The reason it rarely happens is that an internal audit competes with the roadmap every single sprint. Ours has one deadline and nothing else on it.
- It competes with delivery. The audit is real work, and it gets deferred every time a release slips.
- Raw scanner output. Hundreds of thousands of CVEs with no prioritization is a backlog, not a plan.
- Familiarity blind spots. The environments nobody remembers owning are exactly the ones that go unexamined.
- Harder to fund. A finding from inside the team tends to carry less weight in a budget conversation.
- Fixed scope, fixed window. Four to six weeks, with no draw on your delivery capacity.
- Prioritized, not exhaustive. Findings ranked by exploitability and environment, with the fixes that clear the most exposure named first.
- Outside eyes. We have no assumptions about what should be there, which is why we find what shouldn't.
- A document you can act on. Evidence, appendices, and a sequenced plan, which is usually enough to get the work funded.
Who this is for
This is most useful when you're running more infrastructure than any one person can hold in their head, and you have a real reason to need proof of its state.
A CTO who just inherited it all
New in the seat, or post-acquisition, and you want an accurate picture before you commit to a roadmap.
A security lead facing an audit
SOC 2, a customer questionnaire, or a board request, and you need defensible evidence rather than assurances.
A platform team with no headroom
You already know roughly where the problems are. You need them quantified and ordered so the work can get funded.
Anyone planning a big upgrade
A Rails, Kubernetes, or cloud migration is coming, and the scope depends entirely on what you're actually running today.
It's a lot less useful if you run a handful of services on a managed platform and already have automated dependency updates in place. If that's you, we'll say so before you spend anything.
We have been doing this since 2011
FastRuby.io is the Ruby and Rails practice at OmbuLabs. Upgrades and legacy modernization are the whole business, not a side offering, so reading an unfamiliar codebase quickly is the core skill rather than a side effect.
We're also big fans of open source, and we maintain the tooling the Rails community uses to measure exactly this kind of debt.
- RubyCritic
- next_rails
- RailsBump
- skunk
- SoundCloud
- Procore
- ReadyTech
- Power Home Remodeling
- doxo
- Smile.io
- Valid Eval
- Epassi
- SoundCloud
- Procore
- ReadyTech
- Power Home Remodeling
- doxo
- Smile.io
- Valid Eval
- Epassi
- SoundCloud
- Procore
- ReadyTech
- Power Home Remodeling
- doxo
- Smile.io
- Valid Eval
- Epassi
Upgraded our legacy app to Rails 8.1 and Ruby 3.4 on time and on budget. They went beyond expectations and made the transition invisible to our users.
Questions we get
What access do you need?
Read-only, and that's it: your container registry, cluster read access, CI build history, and repository access. No agents, no production changes, and no write permissions at any point.
How long does it take?
Four to six weeks for a typical setup, depending on how many clusters and applications you run. We scope it precisely before we start.
Do we have to be a Rails shop?
No. Ruby is our deepest expertise, but the analysis covers Node, Python, Java, and PHP alongside the container, OS, database, and pipeline layers.
Do you do the remediation too?
Only if you want us to. The assessment stands on its own and your team can execute it. Plenty of clients do continue with us on the upgrade work that follows.
What if the findings are bad?
They usually are, somewhere. The report also names what's working, because knowing your secret management is already sound tells you where not to spend the effort.
How is confidentiality handled?
Under NDA before any access is granted. Findings go only to the people you name, and access is revoked on delivery.
Let's find out what you're actually running
Tell us roughly how big your setup is and what's prompting the question. We'll tell you whether an assessment is worth your money before we quote one. No pressure either way.
- A reply within one business day
- You talk to the engineers who do the work
- NDA before any access is granted
- An honest answer about whether you need this