DEV Community: Snippipedia

Prove Your Cyber Insurance Answers: Commands for the Questionnaire Controls

Snippipedia — Sat, 24 Oct 2026 09:55:12 +0000

I swapped 2 of the usual tags (webdev, ai) for devops and startup because this piece is about infrastructure evidence. Swap back if you prefer.

Someone will eventually ask you to confirm the “yes” boxes on a cyber insurance application. MFA everywhere. EDR on every host. Clean email authentication. Nothing exposed. Here’s how to produce evidence instead of opinions.

Why it matters... in 2022 an insurer and a manufacturer agreed to an order rescinding a cyber policy and declaring it void from inception after the insurer said MFA protected only the firewall. Evidence is the difference between a yes and a maybe.

MFA... find the accounts that break your “yes”

AWS IAM users with console passwords but no MFA-

`aws iam generate-credential-report

wait a few seconds, then (use base64 -D on macOS):

aws iam get-credential-report --query Content --output text | base64 -d \
| awk -F, 'NR>1 && $4=="true" && $8=="false" {print $1}'`

That lists IAM users with a password and no MFA. It misses your identity provider, which is where most staff accounts live. Export the same view from Okta, Entra or Google Workspace. The target list length is zero.

EDR... diff the agents against the inventory

Insurers care whether EDR is on every server, including the forgotten ones-

sort -u assets.txt > a.txt sort -u edr-agents.txt > e.txt comm -23 a.txt e.txt # in inventory, missing from EDR

Anything printed is a host your “yes” doesn’t cover.

Email authentication... anyone can check it, including the carrier

Underwriters look for SPF, DKIM and DMARC, with DMARC set to reject.

dig +short TXT _dmarc.example.com # want p=reject dig +short TXT example.com | grep -i spf

Exposed remote access... scan only what you own

An analysis of published carrier forms says Beazley asks whether RDP is exposed to the internet.

# only scan IP ranges you own or are authorized to test nmap -Pn -p 3389,445,5900 203.0.113.10

Backups... keep a restore log

A nightly job isn’t evidence. A dated restore is.

echo "$(date -u +%FT%TZ) restore-test db=orders result=ok" >> restore-log.txt

Package it

One folder per control, one dated export per answer, one owner per folder. Begin about 90 days before renewal and reconcile every answer with evidence. When the broker’s questionnaire arrives, your answers already exist.

Not legal advice. Ask your broker and a coverage lawyer about rescission rules in your state. Disclosure: I do security consulting at Snippipedia).

Prompt Injection vs SQL Injection: What Transfers, What Doesn't

Snippipedia — Sun, 11 Oct 2026 00:06:39 +0000

If you write backend code, you know the SQL injection fix by heart. Here’s the same bug twice, then what carries over to LLM features and what doesn’t.

Same bug, two languages

1- # Vulnerable: input becomes part of the command
cur.execute(f"SELECT status FROM orders WHERE email = '{email}'")

Fixed: command and data travel separately

cur.execute("SELECT status FROM orders WHERE email = %s", (email,))

2- # Same shape. No placeholder syntax exists for this one.
prompt = f"""You are a support assistant. Only discuss order status.

Customer message:
{user_message}

Knowledge base excerpts:
{retrieved_chunks}
"""
reply = llm.generate(prompt)

There’s no bind parameter for the second block. Chat APIs separate system and user roles, and that helps the model prioritize, but it’s trained behavior, not an enforced boundary. The UK NCSC’s December 2025 write-up says the same thing from the other direction: no inherent distinction between data and instruction, so prompt injection may never be fully mitigated the way SQL injection can be.

What carries over from the SQLi playbook

3 habits transfer directly. Give the “database user” (here, the tools) the minimum rights. Treat everything the model emits as untrusted. And never derive authorization from a claim the model makes.

from pydantic import BaseModel, Field

class OrderStatusArgs(BaseModel):
order_id: str = Field(pattern=r"^[A-Z0-9]{8}$")

ALLOWED_TOOLS = {"get_order_status"} # read-only

def run_tool(call, session):
if call.name not in ALLOWED_TOOLS:
raise PermissionError(f"tool not allowed: {call.name}")
args = OrderStatusArgs.model_validate(call.arguments)
# identity comes from the session, never from model output
return get_order_status(
customer_id=session.customer_id,
order_id=args.order_id,
)

OWASP’s advised mitigations point the same way: limit which tools an agent can use, what each tool can do, and what permissions it holds.

A cheap tripwire (not a fix)

import secrets

CANARY = f"cnry-{secrets.token_hex(6)}" # generate per deployment, keep in config
SYSTEM_PROMPT = f"...internal ref {CANARY}..."

def check_output(text: str) -> str:
if CANARY in text:
alert("system prompt leak") # log it and block the response
return "Sorry, I can't help with that."
return text

This only catches verbatim leaks. An attacker who asks for a paraphrase or an encoding walks right past it. Use it as detection, never as protection.

Test it like the attacker gets to iterate

In NIST’s agent hijacking tests, the strongest standard attack succeeded 11% of the time, while attacks tailored to the target hit 81%. In “The Attacker Moves Second,” researchers from OpenAI, Anthropic, and Google DeepMind broke 12 published defenses with adaptive attacks, most above 90% success, though most had reported near-zero originally. Each defense used its own benchmark, so read the numbers as directional.

A static payload list in CI is fine as a regression check. It isn’t evidence your system is safe.

A design budget- the Rule of 2

Meta’s Agents Rule of 2 says that within one session an agent should satisfy no more than 2 of 3 properties: processing untrusted input, accessing sensitive systems or private data, and changing state or communicating externally. If a feature needs all three, that’s the one to put a human approval step in front of.

Post-Quantum Cryptography Migration- A Practical Starting Point for Developers

Snippipedia — Sat, 03 Oct 2026 12:21:34 +0000

Most production stacks are running RSA and ECC in a dozen places the developer didn't consciously choose — a cloud provider default, an npm package, a library that made the decision years ago. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. These are your drop-in replacements. Where to start-

Step 1: Find your RSA/ECC surface area

// Check your package.json for crypto-heavy deps
cat package.json | grep -i "crypto|jose|jwt|tls|ssl"

Beyond your own code: check your JWT signing algorithm (RS256 = RSA, ES256 = ECC — both need migration eventually), your TLS certificate type (EC cert vs RSA cert), your cloud provider's key management service configuration, and your S3 or blob storage encryption settings.

Step 2: Check library support

OpenSSL 3.x supports hybrid PQC in experimental mode. BoringSSL (used by Chrome, Node.js) has ML-KEM support in active development. For Node.js specifically, the node:crypto module currently follows OpenSSL — watch the OpenSSL PQC roadmap for your version.

For AWS: KMS now supports ML-KEM key agreement in preview regions. GCP Cloud KMS has a PQC roadmap published. Check your region's support before planning migration.

Step 3: Hybrid mode first, not big-bang

NIST recommends running classical and post-quantum algorithms in parallel during the 2025–2027 migration window. For TLS, this means negotiating ML-KEM where both sides support it and falling back to X25519 where they don't. Most modern TLS implementations support hybrid key exchange via config flags — no code changes required for the negotiation layer.

Step 4: Prioritise by data lifespan

Health records, financial data, legal documents, anything with a 5-10 year sensitivity window — migrate these encryption paths first. Session tokens and short-lived auth data can wait. This is about making rational risk-based decisions, not panicking and rebuilding everything.

Full business-level context and the SMB checklist at Here