ITDについて

なぜ作っているか

きっかけは、運営者自身が実際に踏んだ2つの事故でした。1つはAIで書いたコードを公開した直後にAPIキーを抜かれたこと、もう1つは設定ミスで機密ファイルが丸ごと公開されていたことです。どちらも「攻撃が高度だったから」ではなく、「知っていれば防げた基本」で起きました。

同じ轍を踏む人を一人でも減らすために、事故を匿名化して教訓に変え、対策を手の届く形で届けることにしました。

扱うこと・扱わないこと

• 扱う：守り方・事故予防・用語の解説・技術別の安全な設定・事故の歴史と教訓。
• 扱わない：攻撃手順・エクスプロイトコード・他人のサイトへのスキャン・回避テクニック。ITDは攻撃の道具にはなりません。

トーン

煽らず、怖がらせず、正直に。専門用語はかみ砕き、結論から先に書きます。「サイバー防災」の落ち着いた実務をめざしています。

運営者

本サイトは JIT株式会社が運営しています。

• JIT株式会社

編集方針 — 何を根拠に書くか

• 根拠は一次情報のみ。CVEはNVDとCISAのKEVカタログ、製品の脆弱性はベンダー自身のアドバイザリ、設計指針はOWASP・NIST・MDNなどの原典にあたり、各記事の末尾に出典として明示します。
• 断定できないことは断定しません。「現時点で確認されていない」と「無かった」は書き分け、争点がある場合は両論を出典つきで併記します。
• 攻撃手順・実証コード（PoC）は掲載しません。同じ事実から「どう守るか」だけを書きます。
• 実名の組織を扱う記事は、公表済みの事実のみを使い、責任の断定をせず、個人名は出しません。

情報の鮮度をどう保つか

セキュリティ情報は古くなると害になります。脆弱性の記事には「最終確認日」を表示し、公開済みの各CVEをおおよそ2週間ごとにCISA KEVとNVDへ突き合わせて、上流が動いていないかを確認しています。

事実が更新されたときは、書き換えるだけでなく更新履歴として何がいつ変わったかを残します。読者が「いつ時点の情報か」を判断できることを、正確さと同じくらい重視しています。

誤りの訂正

事実誤認・古い情報・分かりにくい説明を見つけたら、該当ページのURLを添えて contact@itdef.net までご連絡ください。確認のうえ速やかに修正し、内容に関わる変更は更新履歴に残します。

自分たちにも同じ基準を当てる

セキュリティを解説するサイトが自分を疎かにしては筋が通りません。本サイトは、依存パッケージの脆弱性を毎日自動監査して見つかった当日に対処し、記事で推奨しているセキュリティヘッダや設定を自分自身にも適用しています。