About ITD

Why this exists

It started with two incidents the operator lived through: an API key stolen moments after shipping AI-written code, and a misconfiguration that exposed secret files wholesale. Neither was a sophisticated attack — both were preventable basics.

ITD turns those incidents (anonymized) into lessons, and delivers defense in a form you can actually act on.

What we cover — and don't

• We cover: how to defend, incident prevention, plain-language terms, safe per-stack configuration, and the history and lessons of past breaches.
• We don't cover: attack walkthroughs, exploit code, scanning other people's sites, or evasion techniques. ITD is not an attacker's tool.

Operator

This site is operated by JIT Inc. (JIT株式会社).

• JIT Inc.

Editorial policy — what we build on

• Primary sources only. CVEs come from NVD and CISA's KEV catalogue, product flaws from the vendor's own advisory, design guidance from OWASP, NIST, MDN and similar originals — and every article cites them at the end.
• We don't state what can't be stated. "Not confirmed as of now" and "did not happen" are written differently, and where a point is contested we give both sides with attribution.
• No attack walkthroughs and no proof-of-concept code. From the same facts we write only how to defend.
• Articles naming a real organisation use publicly disclosed facts only, assert no blame beyond what sources establish, and name no individuals.

How we keep it current

Security information becomes harmful when it goes stale. Vulnerability articles carry a "last verified" date, and roughly every two weeks we re-check each published CVE against CISA KEV and NVD to see whether the upstream record has moved.

When facts change we don't just rewrite: we keep an update log of what changed and when. Letting a reader judge how current a page is matters to us as much as being accurate.

Corrections

Found a factual error, something out of date, or an explanation that doesn't land? Email contact@itdef.net with the page URL. We verify, fix it promptly, and record substantive changes in the update log.

We hold ourselves to the same standard

A site that explains security has no business neglecting its own. We audit our dependencies for known vulnerabilities every day and fix what turns up the same day, and we apply the security headers and settings we recommend in articles to this site itself.