Security chores pile up. Engineers just want to build.

In his Paramify Podcast conversation, RapidFort’s Chief Strategy & Revenue Officer George Manuelian laid out a clear, engineer-first philosophy: take the drudgery out of vulnerability work, prove what’s actually running, and turn compliance from a brake pedal into a by-product of sound engineering.

This article distills George’s discussion, in his words and framing, into the core ideas that guide RapidFort’s approach today.

“It’s not sexy. It’s laundry. It’s the stuff you know you need to do, but you don’t want to. You’d rather outsource it or have a tool do it for you.” - George Manuelian, CRO, RapidFort

Built by Engineers, for Engineers

RapidFort’s origin story begins with a familiar crunch - a major refactor completed in months, then blocked at the finish line by a security review. Patching by hand took quarters. The lesson wasn’t “do less security.” It was “engineer a better way.”

As George put it, the company’s DNA is about helping engineers fix the problem without forcing a false choice between speed and safety.

Key principles he emphasized:

• Work with what teams already ship. RapidFort doesn’t need source code to make meaningful progress on risk.
• Automate where time is leaking. Let pipelines handle the repetitive parts. Save human effort for architecture and features.
• Prove reality, not intent. Map what actually executes and keep evidence current.
  

The Scale Problem: Vulnerability Debt Outpaces Human Bandwidth

George shared numbers that feel uncomfortably common:

• Teams spending about 20% of developer time on tickets, patch hunts, and research.
• An enterprise reporting 7,000,000 total vulnerabilities, with 2,000,000 labeled critical.
• A security group closing 100,000 CVEs per month while 175,000 new ones arrive.
  

Then there’s AI. “AI doesn’t sleep,” George said. It can find vulnerabilities in 30 seconds that once took 30 days. Discovery is accelerating, and exploit research is faster than ever. If your process relies on manual triage and one-off fixes, you will fall behind.

The only sustainable posture, George argues, is to start clean and stay clean automatically at every build.

Containers Changed the Patch Playbook

CISOs often ask, “We had golden VM images. What’s different with containers?” George’s answer is blunt:

• Volume and Ephemerality: Where you had hundreds of VMs, you now have thousands - even tens of thousands - of containers spinning up and down constantly.
• Immutable Reality: You don’t SSH and patch a running container. To fix, you rebuild and redeploy.
• Developer Loop: Real remediation happens in the build system. Non-developers can’t hot-patch containers the way they could a VM.
  

The net effect: remediation belongs in CI/CD, not as a weekend fire drill on live systems.

Open Source at the Core: “The Giant Washing Machine”

George describes RapidFort as a “giant washing machine” for open source:

• Respect upstream. Leverage the strength of broad, public scrutiny across Debian, Ubuntu, Red Hat, Alpine, and more.
• Patch once, distribute cleanly. Don’t make every team reinvent the same fixes.
• Avoid lock-in. Keep bases compatible with upstream to preserve freedom of choice. This is critical for regulated and long-lived systems.
  

This is not about rewriting the ecosystem from scratch. It’s about cleaning and curating what millions already trust so teams can ship safer software without swapping their foundations.

“Start Clean, Stay Clean”: What That Looks Like in Practice

George’s framing is intentionally simple:

• Begin with clean images. If your baseline is full of known CVEs, you’re already behind before the first line of your code compiles.
• Continuously rebuild with fixes. Each build cycle should pull in upstream remediations and remove what you don’t need.
• Prove what’s really running. Keep accurate inventories and execution-aware records that your auditors and incident responders can use.
  

The “stay clean” part matters as much as the “start clean.” Vulnerabilities don’t arrive on a schedule. Your process must keep pace by default, not as an emergency ritual.

Hardening Is About Reality, Not Reachability

George cautions against the “reachability” trap - assuming a firewall or network segmentation makes a vulnerability irrelevant.
Attackers jump fences. If they land in a container and find curl, package managers, shells, and unused tools, they have everything they need to move laterally or escalate.

The safer stance is to remove what isn’t mission-critical. Like your phone with 150 apps you don’t use, extra components are just extra risk.

Cadence: Patch at the Speed You Build

“How often should we deploy?” is the wrong question. George flips it to “How often do you build?” Patch on that cadence. Whether you build multiple times per day or monthly, each build should incorporate updates and hardening. That’s how you keep pace without stalls or surprise regressions.

Real-World Results (Framed the Way George Shared Them)

• A customer facing roughly 3,582 CVEs estimated six engineers and three months to remediate.
• With profiling, clean bases, and removal of unused components, they dropped to fewer than 500 CVEs in about two hours, then to 3 CVEs within a week. Those few weren’t patchable at the time, and there were no source code changes.
• Image size shrank from about 1.8 GB to about 262 MB, improving performance and build times.

These outcomes illustrate the compounding effect of starting clean and shipping only what’s needed.

Compliance: Turn Evidence Into a Continuous Output

George is clear - this isn’t about buzzwords or checkbox theater. It’s about evidence that stands up for programs like FedRAMP and CMMC, and for internal risk reviews.

• Generate SBOMs and a Runtime Bill of Materials (RBOM™) that reflect what’s actually executing.
• Keep proof current at every build so compliance readiness accelerates instead of pausing delivery.
• Produce artifacts that map directly to controls and Plans of Action and Milestones (POAMs) or self-attestations - the formats your governance teams need.

Compliance, in George’s view, should ride along with engineering, not work against it.

Why Upstream Alignment Matters (Especially in Regulated Spaces)

Enterprises - particularly public-sector and defense programs - need confidence they can maintain software lifecycles over years without being boxed in.

George underscored that staying true to upstream open source gives teams longevity, flexibility, and a broad community of scrutiny. It also reduces the blast radius if a vendor relationship changes. You’re not forced to rip out foundations to keep operating.

The Road Ahead: Closing the Loop

George’s forward look is about closing the loop between build-time and runtime:

• Let runtime observations sharpen build-time decisions.
• Push as much remediation as possible into automation so human time goes to design and verification.
• Keep the proof flowing for security teams, auditors, and incident response.

As he put it, the aim is simple - give engineers their time back while raising the security floor for everything you ship.

Want to Hear It In George’s Words?

This article captures the conversation’s essence, but the full nuance, stories, numbers, and philosophy are in the Paramify Podcast episode featuring George Manuelian, Chief Strategy & Revenue Officer at RapidFort.

Listen to the full episode here: Paramify Podcast — “Giant Washing Machine of Open Source: Container Security with George Manuelian”

If your team is wrestling with vulnerability debt, patch cadence, or audit evidence, this conversation is a must-listen on building secure software the engineer-first way.

‍