AppSecNews
RASP Commercial Growing

K2 Cyber Security

by New Relic

A runtime protection agent that models an application's expected execution flow and flags deviations, detecting injection and memory attacks without signatures; technology now part of New Relic.

Visit newrelic.com (leaves AppSecNews, opens in a new tab) Leaves AppSecNews for the vendor's own site.

No endorsements yet

Run K2 Cyber Security in production? A named recommendation helps the next team shortlisting it.

Recommend this tool

Endorsers verify their identity through LinkedIn. Titles and companies are self declared, shown as they were when each person signed, and reviewed by an editor before anything is published. Endorsements are never paid for.

What we still need to verify : 3 points in this profile are not yet confirmed against vendor documentation.
  • K2 technology was acquired by New Relic and the standalone product no longer stands alone: confirm current productization and naming
  • Language coverage and deployment options under current ownership: verify against vendor documentation
  • Integration list: largely unconfirmed, verify

Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.

What it does

K2's approach was deterministic rather than probabilistic. Instead of inspecting request payloads for attack patterns, the agent builds a map of the application's legitimate control flow, the set of execution paths the code is actually capable of taking, derived from the running application itself. At runtime it then watches whether execution follows one of those known paths. An injected command, a deserialization gadget chain or a memory corruption exploit ultimately has to redirect execution somewhere the application was never built to go, and that deviation is the detection signal. The claim that follows is low false positive rate: there is no pattern to tune, and an alert means control flow left the known map, not that a request looked suspicious.

The agent also produced findings usable before production, identifying vulnerable code paths exercised by functional or QA traffic, which places it as much in interactive testing territory as in protection. That testing angle survived the acquisition most visibly, with the technology feeding New Relic's runtime vulnerability capability rather than shipping as an independent product.

Where it fits

In its original form this was a production and pre-production agent, installed alongside the application by the platform team and monitored by security. The pre-production use case is the easier sell: run the agent during functional testing, see which vulnerabilities are actually reachable from real request flows, and prioritize accordingly. Anyone evaluating it now should treat it as a component of the New Relic platform and confirm what is available, because the standalone offering is not what it was.

Strengths

  • Control flow modeling detects exploitation of unknown vulnerabilities, since the technique does not depend on knowing the payload.
  • Deterministic signal means alerts generally warrant investigation, which is not true of pattern-based runtime tooling.
  • The same instrumentation supports pre-production reachability testing and production detection.

Limitations

  • The product no longer exists as an independent offering, so evaluation means evaluating New Relic's platform and accepting its deployment model.
  • Control flow analysis catches deviation from expected execution. Attacks that abuse legitimate functionality, such as broken access control or business logic abuse, do not create that deviation.
  • Documentation and community knowledge from the standalone era are sparse and aging, which makes independent verification of behavior harder than for larger products.

Who it suits

Relevant mainly to teams already committed to New Relic who want runtime vulnerability context from agents they are deploying anyway. Anyone specifically seeking K2's control flow integrity technique as a standalone protection layer should look elsewhere, as should teams whose main concern is authorization and business logic abuse rather than injection and memory-level exploitation.

Used K2 Cyber Security? Recommend it under your own name and title.

Recommend this tool