OWASP Secure Coding Practices – Quick Reference Guideの訳語が不適切ではないのか？とメールを頂きました。
ブログにして見ていただく方が良いと思ったので公開します。
https://blog.ohgaki.net/owasp-
secure-coding-practices-quick-reference-guide
上記の投稿におきまして、原文中の ‘technology agnostic document’ を「技術的不可知論文書」と訳され、
> この文書が取り扱うセキュアコーディングの本質が理解されていな
い、理解されることがない、と嘆いていることを意味します。
と記載されていますが、これは誤訳で ‘agnostic’ は情報技術の分野では「不可知論」ではなく「依存しない」という意味があり、文脈から同文書ではこちらの意味で使用しているのではないかと思われます。
(参考)
https://en.wiktionary.org/wiki/agnostic#Adjective
https://whatis.techtarget.com/definition/agnostic
https://eow.alc.co.jp/search?q=agnostic
確かにOWASP Secure Coding Practices – Quick Reference Guideは「セキュアコーディングの本質を知らなくても使えるチェックリスト」です。「（知識/理解に）依存しないチェックリスト」としても誤訳ではないでしょう。
Agnostic には元々、神の真理は人の理解が及ばないといった意味合いがあります。
【名】不可知論者◆人間は神の存在を証明することも反証することもできないと唱える人。
【形】《哲学》不可知論（者）の
指摘頂いた通りITでは「汎用的」に近い意味の使われ方もあります。著者は両方の意味を上手くミックスして使っていると解釈しています。
このお問い合わせメールに対して以下のように返信しました。
メールありがとうございます。セキュアコーディングは2000年代初めから提唱されています。書籍も2003年頃には複数出版されていました。
セキュアコーディングはコンピューターサイエンスを学ぶ者とっては基礎の基礎となる構造と原理から導き出される原則に基づいています。
https://blog.ohgaki.net/
secure-coding-structure-principle
https://blog.ohgaki.net/cert-top-10-secure-coding-standard
現存するWebアプリのほぼ全て、アプリケーションの多くが、セキュアなソフトウェア構築に必要な基本構造さえ持っていません。
https://blog.ohgaki.net/
security-anti-practice-designless-software-security
セキュアコーディングを提唱するコンピューターサイエンティストが以前から（50年代から）知っている妥当でないデータによって発生する不確実性（リスク）について、多くの開発者が理解していません。
https://blog.ohgaki.net/
learning-input-validation-
from-formal-verification-and-combinatorial-explosion
理解していれば妥当性検証無しのデータを放置するはずがないです。
セキュアコーディングは2000年代になってから急に提唱された物ではありません。始まりは90年代初めにまで遡ります。
https://blog.ohgaki.net/
secure-defensive-programming-history
OWASP Secure Coding Practicesの初版が何時書かれた物かは把握していませんが、書かれた当時、既に著者が「開発者がセキュアコーディングの本質を理解するのは困難である」と考えてしまっても当然の状況にありました。
半世紀以上も前に科学的結論がでていること、10年以上提唱されている基礎的対策でさえ正しく理解されていないこと、OWASP TOP 10 の初版では第一の脆弱性が”入力検証”でしたが、多くの開発者（そして少なくない”セキュリティ専門家”まで）が誤解してしまったので書き替えた、という経緯もあります。
メールには記載しなかった参考ブログ：
OWASP Secure Coding Practicesは「概念」を説明する文書ではなく、ほぼ単なる「チェックリスト」の体裁になっています。これは「セキュアコーディングの本質を理解が難しい」とする前提があると考えるのが妥当だと思われます。
「汎用的に使えるチェックリスト」よりは「本質を理解しなくても使えるチェックリスト」を意味する可能性の方が高いと思います。（チェックリストは本質を知らない人でも、ある程度の成果を上げられるツールでもあります）
これは著者にだけ正確に判断できることですが、状況から考えると「本質が理解されることは困難」とする方が妥当性があります
このため、一般に解釈される「不可知論」と訳すことが適当だと判断しています。
現実的に、今でも全く理解されていない、多くのソフトウェアセキュリティ専門家/コンピューターサイエンティストが啓蒙することさえ諦めている、という状況もあります。正に「不可知論」ではないでしょうか？
いかがでしょうか？
何れにせよ「入力データ検証無し」のソフトウェアセキュリティでは土俵の上にも立って居ない状態です。
ISO 27000には遡ると2000年からわざわざ詳細な入力データ検証のやり方まで記載していました。ですがこれを実装しているWebアプリケーションはほとんどありません。これが現状です。
現在ではIT業界で割と一般的に使われているagnosticですが、このガイドが書かれた2010年頃はまだ一般的とは言えない状況だったように思います。
‘technology agnostic document’は普通に書くと’technology indipendent document’または’technology neutral document’とするのが当時の（今でも）一般的な記述方法だったように記憶しています。agnosticとしたのは、現在割とIT業界で一般化したagnosticの用法とは異り、特別な意味を持っていると感じました。
単純に「技術に依存しない文書」と書きたいなら「technology independent document」と書くだけです。しかし、著者はそうしなった。”agnosticがそもそも持つ意味”に意味があるはずです。
この為、より一般的な訳語となる「不可知論」とする方が妥当である、と判断しています。
このチェックリストの意図、本質を理解した方が良いのだけれど少なくともこれくらいは実施すること、にも合致していると思います。
EUのGDPRに対する勝手な考察
EUのGDPRが施行されました。GDPR違反に問われると、一回目の故意でない問題は文書による警告のみ、二回目以降は1000万ユーロまたは2000万ユーロ以上の制裁金、と最初とそれ以降の制裁内容が大幅に異なっています。天と地ほどの差がある、と言ってよいくらいです。
このような内容になったのはソフトウェアの問題による個人情報漏洩を念頭に置いたものではないか？と思っています。
先に書いたようにISOのセキュリティ標準では2000年からセキュアコーディング/セキュアプログラミングを念頭に置いた規格となっており、2014年の改訂でセキュアプログラミング技術は体系化され一般化した、としています。標準化が大好きなEUが国際ITセキュリティ標準に対して甘い、とは考えられません。
ソフトウェアなどのセキュリティ問題が原因でGDPR違反となった場合、最初は警告で済ませるが二回目以降が無いようしっかりやるべき事はやっておくように、二回目以降は問答無用で制裁金を課す、という意味合いではないでしょうか？
セキュアコーディングの基礎さえ実装していない場合、ソフトウェアのリスクは指数関数的以上に複雑化（＝リスク上昇）します。
日本はまだGDPRが直接影響する国ではないのでマシですが、セキュアコーディングで実装していないアプリケーションは怖くて使えません。実際、東京都の納税サイトからクレジットカード情報が盗まれたStruts2アプリの問題も、アプリでセキュアコーディングを行っていれば問題を防止できた事例です。
ソフトウェアのセキュリティに対して責任を持つのは基本的にはアプリケーションです。フレームワークやライブラリの責任には出来ないモノが多数あります。ソフトウェアのセキュリティ向上にセキュアコーディングの基本概念／原則は欠かせないのですが、残念ながら十分に普及している、とは全く言えない状況です。
セキュアコーディングの原則：
GDPRの影響もあってか、関係なくか分かりませんが、2017年版OWASP TOP 10もセキュアコーディングで実装していないと対応できない問題を脆弱性TOP10に入れてきています。これも無関係には思えません。
2017年版OWASP TOP 10の策定は荒れた状態でした。その中には、「WAFを強くプロモーションし過ぎる内容」であることを問題視する意見もありました。アプリケーションですべきセキュアコーディング原則の実装をWAFで実装してしまってはダメだ、GDPRには対応できない、とする考えもあったのかも知れません。
取り敢えず一般公開するアプリには、CERT Top 10 Secure Coding Practices、OWASP Secure Coding Practices – Quick Reference Guideは実装/実践しましょう。
”独自”のセキュアコーディング標準の構築と実装もお忘れなく！ ※
※ CERTの言語用セキュアコーディング標準はあくまで言語用であり、自分の環境（言語／フレームワーム／ライブラリなど）にあったセキュアコーディング標準の構築と実践が必要です。
Leave a Comment