DEV Community: Raja Nagori

Tenant Isolation Is a Boundary, Not a Filter

Raja Nagori — Tue, 25 Aug 2026 13:30:00 +0000

If two customers share a platform and isolation is “UI only,” you have a liability.

Problem

Every request must answer: whose data is this? If the client supplies orgId and you politely believe it, you already lost.

Solution concept

Authenticate the caller
Load memberships
Bind tenant context for this request
Scope DB reads/writes to that tenant
Keep files/workspaces under the same identity

The org dropdown is a reminder, not the control plane.

Residual risk

Rare bypass paths need review. App filters without DB enforcement are thinner. Isolation shrinks blast radius, it is not absolute safety.

Try a real console - leave feedback

Review / discuss: GitHub Discussions #11

Malicious updates: why “just npm update” is a security decision

Raja Nagori — Thu, 20 Aug 2026 15:00:00 +0000

Routine upgrades can introduce new exfil channels behind familiar package names.

Problem

npm update is not a hygiene chore. It is a content-distribution event for every package in range.

Split “security hotfix” lanes from “dependency refresh” lanes so urgency cannot be used to skip review.

Solution concept

Ship one control at a time, measure bypasses, then add the next. A single enforced check beats a binder of unenforced best practices.

Treat dependency bumps as deployments: review, stage, canary, then promote. Especially for packages that run code at install or import time.

App depends on a helper with caret/range policy
Malicious version publishes under the same name
Update command pulls the trojanized release
Runtime or install path executes new behavior

Field notes

Separate bots: one opens dependency PRs, another cannot merge them. Require a short threat note on PRs that touch lockfiles for internet-facing services—“what could a malicious version do here?”

Residual risk

You will still miss clever payloads. Pair process with runtime detection; neither alone is enough.

Try it - then talk back

Explore the concept in Supply Chain Attack Simulator (SCAS):

If you face any issues - Github Issues - RAJANAGORI

Stop Rebuilding Your Pentest Lab for Every Engagements

Raja Nagori — Wed, 19 Aug 2026 11:30:00 +0000

Nightingale is a Docker pentest stack with a browser Command Center terminals, scans, VPN, VS Code, and team controls in one place.

I used to burn the first hour of an engagement on setup: install the missing package, fix the broken VPN route, sync notes from three terminals, then remember the new analyst still does not have a working lab.

That hour never shows up in the report. It still costs the client.

Nightingale flips the default. One Docker image, 200+ tools, and a web Command Center so the lab is the same whether you are on a laptop or a hosted console.

The pain (in one sentence)

Toolchains sprawl across hosts, environments drift, and onboarding a tester still takes longer than the first recon pass.

What you actually get

Surface	Why it matters
Multi-terminal + file explorer	Parallel shells in the browser; tree stays with your cwd
Security Scans / Playbooks / Schedules	Queue tools, chain steps, schedule repeats, export Markdown
VPN	Upload `.ovpn`, connect in an isolated container for HTB/THM-style labs
VS Code in-browser	Edit without leaving the engagement
Users + MFA + audit	Shared console without shared accountability gaps
Optional AI	Command suggestions + scan explainers with your own key

Same product idea on nightingale-security.com open core under OWASP, Black Hat Arsenal track record, pull from GHCR or use the hosted dashboard.

Walk the UI (screenshots)

Land in the console shell + explorer for the active org/engagement:

Submit scans without babysitting a random tmux session:

Connect lab VPN without killing your console network:

Manage who can touch the console:

Quick start (hosted)

Register: dashboard.nightingale-security.com/register
Login: dashboard.nightingale-security.com/login
Open Nightingale Console, pick an engagement, run a command or submit a scan.

Quick start (self-host)

docker pull ghcr.io/rajanagori/nightingale:stable
docker run -d -p 8080:8080 --name nightingale ghcr.io/rajanagori/nightingale:stable
# open http://localhost:8080

Spin it up when the test is scheduled. Tear it down when you are done. No 24/7 lab tax.

Why this sticks for teams

Engagements are scoped (org + engagement context), so org1 and org2 do not share home dirs, scan history, or VPN configs by accident. That matters when two programs run in parallel and you cannot afford “wrong folder, wrong VPN” mistakes.

The browser VS Code tab keeps notes and scripts next to the shell. Optional AI settings let you bring your own OpenAI or Azure key for scan explainers useful when you want a first pass narrative over raw tool output, not a black-box vendor model you cannot control.

Who this is for

Pentesters and security engineers who want reproducible tooling and a browser first ops surface not another “install these 40 packages” wiki page. Also useful for lab instructors and CTF crews who need the same environment every time someone joins.

If that sounds like your workflow tax, start here: nightingale-security.com → register → open the console.

Compromised packages: same name, new behavior, old trust

Raja Nagori — Tue, 18 Aug 2026 15:00:00 +0000

Trust is sticky. Version bumps can ship new exfil while APIs stay stable.

Problem

Same package name. Familiar API. New version. Hidden side effect on load or on a hot method. That is maintainer/release compromise - not a typo.

For top-N packages by import graph reach, require human approval on version bumps—even patch lines.

Solution concept

Ship one control at a time, measure bypasses, then add the next. A single enforced check beats a binder of unenforced best practices.

Pin + human review for critical deps
Verify provenance attestations when available
Alert on novel egress from package code
Prefer smaller dependency surfaces for trust boundaries

Users already depend on a trusted package name
Maintainer account or release pipeline is abused
New version preserves exports but adds a beacon path
Consumers update routinely and inherit the behavior

Field notes

High-reach libraries (HTTP clients, auth helpers, logging) deserve slower upgrade trains. A patch bump that adds network calls to unfamiliar hosts is a stronger signal than a CVSS score alone.

Residual risk

Authorized malicious publishes beat signature checks. Layer identity, behavior, and blast-radius reduction.

Try it - talk back

Explore the concept in Supply Chain Attack Simulator (SCAS):

If you face any issues - Github Issues - RAJANAGORI

Dependency confusion in one table: internal scope vs public higher version

Raja Nagori — Thu, 13 Aug 2026 15:00:00 +0000

Problem

Your CI asks for an internal package. The public registry answers first with 999.999.999. Installers that maximize version will take it. That is dependency confusion no phishing required.

Print the resolved registry host in CI logs and alert on public hosts for private scopes. Make confusion visible.

Solution concept

Ship one control at a time, measure bypasses, then add the next. A single enforced check beats a binder of unenforced best practices.

Scope + registry map for every internal namespace.
Exact pins; no caret/range on private packages.
Assert resolved URL host in CI against an allowlist.
Treat lockfile resolved fields as security-relevant artifacts.
Internal package exists only on a private registry
Build config also searches the public registry
Attacker publishes the same name with a higher version
Installer prefers public artifact; malicious code runs

Field notes

Print resolved URLs during install in CI. If an “internal” package suddenly resolves to a public host, treat it as an incident even when tests pass. Scoped registry maps belong in the repo, not only on individual laptops.

Residual risk

Misconfigured local .npmrc bypasses org policy. Verify resolution in the same environment that ships artifacts and not only on a secure bastion.

Try it, then talk back

Explore the concept in Supply Chain Attack Simulator (SCAS):

If you face any issues - Github Issues - RAJANAGORI

Typosquatting is not “user error” - it is a package resolution problem

Raja Nagori — Tue, 11 Aug 2026 15:00:00 +0000

Why lookalike package names bypass review, and how to reason about install-time vs require-time risk.

Problem

If your threat model starts at “crypto of the tarball,” you are already late. Most teams lose at name resolution: the wrong package string installs cleanly, exports a familiar API, and executes side effects before any business logic runs.

Add a CI check that fails on unexpected new package names in the lockfile for protected services. Cheap control, high signal.

Solution concept

Ship one control at a time, measure bypasses, then add the next. A single enforced check beats a binder of unenforced best practices.

Practical controls:

Control	Why it helps
Lockfiles + `npm ci`	Stops casual name drift on install
Name allowlists in CI	Fails builds on unexpected package strings
Lifecycle script policy	Limits install-time execution
Boot-time network watch	Catches require-time beacons

Do not equate “tests passed” with “no side effects on require.”

Attacker publishes a lookalike name near a popular package
Developer (or lockfile drift) installs the wrong name
Malicious module runs at install or first require
Payload phones home or in safe labs, posts to localhost only

Field notes

Watch for packages whose README is a thin clone of a popular project, publish times clustered after a viral blog post about that project, and maintainers with no prior history. In CI, prefer failing on unexpected new package names over paging after exfiltration.

Residual risk

Lookalike detection is fuzzy. Attackers iterate names faster than blocklists. Combine identity checks with behavior signals unexpected scripts, unexpected network knowing both have gaps.

Try it - then talk back

Explore the concept in Supply Chain Attack Simulator (SCAS):

If you face any issues - Github Issues - RAJANAGORI