Do You Need a Penetration Test?

A penetration test replaces assumption with evidence. We commissioned one on our own production cluster — an independent specialist, black-box methodology, defined scope. What that engagement produced stays internal. But the discipline of running it, and the questions it forces you to answer about your own environment, is what this post is about.

The Environment We Put to the Test

The infrastructure the test ran against is the same cluster that's been the setting for the last two posts here — the AI governance architecture and the LLM Guard deployment on OpenShift. It runs OKD — the open-source community distribution of OpenShift, not the enterprise Red Hat product.

OKD is the upstream project from which Red Hat's enterprise OpenShift is derived. The core architecture is the same: Security Context Constraints enforced at the API level, the MachineConfigOperator managing node configuration as declared state, built-in audit logging in the control plane. Red Hat's enterprise offering adds support contracts, certified hardware integrations, and a dedicated roadmap for OpenShift AI — a platform for governed AI workloads in regulated environments that we intend to explore seriously. That's a different track from what this cluster is. What FEDLIN operates is a practical, production-grade alternative built on the same foundation: an upgrade from K3s, the lighter distribution we used to self-host localized services while the operational model and hardware caught up. The penetration test was run on the OKD cluster at full scope.

Starting Where an Attacker Would

A penetration test puts a skilled operator in the attacker's position with a defined scope and a mandate to reach as far as they can from a realistic starting point. What it produces is a traced attack chain: every step the tester took, every control they passed through, every point where a specific change would have broken the path.

A finding that looks low-severity in isolation can be the first step in a chain that reaches something critical. The penetration test maps that chain — where it exists, what it passes through, and how far it extends — before someone else traces it under less controlled conditions.

How Engagements Are Scoped

Penetration testing isn't a single service — scope defines what gets tested and from what starting position. The common scoping categories, and what each covers:

External network testing starts with no access at all — the position of an attacker who has identified your organization as a target. The tester works against publicly reachable infrastructure: exposed services, authentication interfaces, DNS enumeration, any entry point visible from the internet. It answers whether the perimeter holds against an attacker who hasn't yet obtained any internal access.

Web application testing focuses on a specific application at the authenticated layer. Authentication flows, session management, authorization logic, API endpoint behavior, and how the application processes input — OWASP Top 10 vulnerabilities get tested against the real implementation, not a checklist. Broken access controls, privilege escalation through logic flaws, and injection vectors in API handlers often don't surface in a network scan because they require operating inside an authenticated session.

Internal network testing changes the starting assumption entirely. The tester enters as someone who already has a foothold — a compromised employee account, a device on a LAN segment, a contractor credential. It bypasses the question of whether the perimeter holds and asks what happens once it doesn't. The category our own engagement fell into — and the one that tends to produce the most consequential findings.

Cloud and Kubernetes infrastructure testing examines the configuration of cloud environments and container orchestration platforms — IAM policy assignments, RBAC configurations, secrets management, network policy enforcement, and the controls that govern what workloads can reach and do. Misconfigurations at this layer tend to carry significant blast radius: a permissive RBAC binding on a single service account can propagate access across an entire cluster.

Social engineering assessments test the human layer through phishing simulations, pretexting, and physical access attempts. These are scoped separately and require specific authorization documentation covering the staff population involved.

The right combination depends on what the environment runs and what the risk profile requires. The scoping call is where that gets defined.

What These Engagements Surface

Real attackers don't start as administrators. They start with whatever access they can obtain — a phished credential, an exposed service endpoint, a contractor account provisioned for a legitimate engagement. The question isn't whether your perimeter holds against someone who starts with nothing. It's what someone can accomplish once they have a reasonable starting point.

That gap — between a limited foothold and what it can reach — is rarely obvious from the inside. A configuration that looks acceptable in isolation can open a path an attacker follows all the way to something critical. Scanning tools don't trace that chain. They identify known signatures in isolation. A penetration tester traces the chain deliberately, following documented techniques to find the path before an attacker does.

What the engagement produces is a documented record of what was reachable, from where, and what would have stopped it. Every finding is severity-rated and traceable to the specific step in the chain it represents — the input a prioritized remediation plan is built from.

How the Engagement Actually Runs

Penetration testing doesn't require specialized hardware for most engagement types. Our own test ran entirely over VPN and SSH — the same remote access a legitimate contractor would use. External network, web application, and cloud infrastructure tests follow the same pattern: define scope, provision appropriate access, run the engagement, deliver the report. No on-site visit, no client-side hardware procurement, no IT project to set it up.

Internal network testing is the exception where physical placement matters — testing from inside a location, on the LAN, against the network as it looks from the inside. For that scope, FEDLIN ships a small pre-configured device the client plugs into the target network segment. The tester accesses it remotely over a secure tunnel. No on-site coordination required, and the device is documented in the SOW and wiped after the engagement concludes. What would otherwise require scheduling an on-site visit becomes a question of where to plug something in.

The engagement structure is consistent across types: a scoping call to define targets, methodology, testing window, and rules of engagement; active testing with out-of-band notification if a critical finding surfaces mid-engagement; a draft report delivered within the agreed timeframe, with findings severity-rated and mapped to the frameworks in scope — SOC 2, PCI DSS, NIST 800-53, or a combination; a client review period; a final report. An optional re-test validates that Critical and High findings have been closed, producing a re-test attestation that maps directly to what auditors and enterprise procurement require.

Who Actually Needs One

The compliance-driven case is defined by framework requirement. SOC 2 Type II auditors expect it as evidence for the access control and change management control families. PCI DSS requires annual external and internal testing for environments in scope for cardholder data. For either of these, the report is an audit artifact, and the absence of one is a gap assessors document.

The non-compliance case is often more valuable as a first engagement. An organization that has deployed real security tooling and wants a clear answer to whether it holds against someone actively trying to break it — that's where a penetration test produces the most durable change in posture. The findings replace an assumption with a documented record of what an attacker can actually reach from a realistic starting point.

The business development case is worth naming separately. "When was your last penetration test?" appears on most enterprise security questionnaires and federal procurement checklists. A recent report with documented remediation closure is the answer. The absence of one is where deals stall and procurement timelines extend.

FEDLIN's penetration testing is delivered through its partner network — a certified specialist (GREM, PNPT) with over a decade of enterprise security experience across offensive security, malware analysis, and cloud-scale incident response. That specialist ran the pen test on FEDLIN's own infrastructure and is who runs a client engagement; findings feed directly into remediation when a client chooses to close them together. The scoping call is where it starts.