RedForge / Code & Cloud

The flaws already sitting in your repository.

Read the way a maintainer would rather than guessed at from outside — plus the libraries carrying known CVEs, the buckets left open, and the assistant you added last quarter that nobody is logging.

Send us your scope See what it costs

What is covered

Five reviews that need something the outside cannot see.

The running-application assessments test what an attacker reaches. These test what they would reach next, and they need access you grant deliberately.

Source code security review

The secrets and flaws already in your repository, found by reading the code rather than probing a black box.

How it works

We review your repository for hardcoded credentials, unsafe sinks — SQL injection, XSS, SSRF, path traversal, command injection — weak cryptography and missing authorization checks. Every finding points at the exact file and line.

How it helps

Snippets are anchored deterministically to real source. Anything the analysis could not confirm against the actual file is dropped rather than shipped — a hallucinated line number is worse than no finding.

Dependency and known-CVE review

The open-source libraries in your project, checked against the OSV.dev database — with the exact fix version.

How it works

We scan your dependency manifests — Python, npm, Go, Ruby, PHP, Maven — against OSV.dev’s aggregated vulnerability database. Each hit maps to a CVE or GHSA identifier, its severity, and the version that fixes it.

How it helps

You get a list that names the upgrade rather than the risk category, so the work is a version bump somebody can do this week.

Cloud configuration review

Misconfigured IAM, open storage and exposed services — the CIS-benchmark findings your cloud provider will not volunteer.

How it works

We ingest your cloud configuration — AWS, GCP, Azure, Kubernetes — through read-only tooling and check it against CIS benchmarks. We hold no credentials of yours: either your team runs the collector and sends the JSON, or we use a time-boxed read-only role.

How it helps

Catches the mistakes that never show up from outside because they are one policy change away from mattering.

Cloud storage security review

Find the AWS S3, Azure Blob and Google Cloud buckets open to the public before somebody else does.

How it works

We enumerate the storage buckets tied to your company and test each for public read and public write access, then confirm by hand what a stranger could actually retrieve.

How it helps

Catches the bucket a developer opened for a quick test two years ago and never closed — usually the one holding exports.

AI and LLM security testing

The assistant you added last quarter answers customers, reads your data, and almost nobody is logging what it says.

How it works

We plant harmless marker codes in the assistant’s context and check where they surface: in another user’s conversation, in a reply that should not have that document, or in a tool the assistant is allowed to call. Tested against the OWASP Top 10 for LLM Applications.

How it helps

A marker that reappears somewhere it should not is evidence, not a judgement about model behaviour — which is what makes an LLM finding provable at all.

Remediation is never presented as a diff of your code. Where we tested your running application from the outside, we did not read your source — so the fix is given as an illustrative pattern in your framework, captioned as such. An unrecognised framework gets no code rather than another framework’s code.

Ready to scope a code or cloud review?

Tell us what stack you run and how you would prefer to grant access. Read-only, time-boxed, and revoked when the engagement closes.

Send us your scope