正解：ア
各選択肢の解説
ア脆弱性の原因になる書き方を避け、欠陥を作り込まないようにプログラムを書くこと。
正解。セキュアプログラミングは、開発の段階で脆弱性を作り込まないための 書き方です。入力値の扱い方やメモリの使い方など、欠陥の原因になる書き方を 最初から避けるので、後から見つけて直すより手戻りが少なく済みます。
イ完成したシステムに疑似的な攻撃を行い、実際に侵入できるかを確かめること。
誤り。これはペネトレーションテストの説明です。どちらも脆弱性に関わる ため混同しますが、こちらはできあがった物を攻めて確かめる検査です。 作る段階で防ぐのか、作った後に確かめるのかで区別します。
ウ公開中のWebアプリケーションへの通信を検査し、攻撃とみられるものを遮断すること。
誤り。これはWAFの役割です。Webアプリケーションを守る点は同じですが、 WAFはプログラムの外側に置く防御で、欠陥そのものは残ります。プログラムを 直すのか、手前で通信を止めるのかで区別します。
エソースコードを読みにくい形に変換し、攻撃者に処理の内容を解析されにくくすること。
誤り。これは難読化の説明です。解析に手間をかけさせることはできますが、 脆弱性がなくなるわけではなく、根気よく調べれば見つかります。隠すことと、 欠陥を作らないことは別物です。
理解を深めるために
穴を作らないように書くこと
セキュアプログラミングは、脆弱性を後から見つけてふさぐのではなく、 そもそも作り込まないようにプログラムを書くことです。建物でいえば、 完成後に防犯カメラを付けるのではなく、設計と施工の段階で鍵の掛からない窓を 作らないようにする考え方です。
なぜ開発の段階で防ぐのか
脆弱性の多くは、プログラムの書き方そのものから生まれます。
- 入力値を文字列連結してSQL文を組み立てる → SQLインジェクション
- 画面に出力する値をエスケープしない → クロスサイトスクリプティング
- 確保した領域の大きさを確かめずに書き込む → バッファオーバーフロー
こうした書き方を避けるための規約を決め、レビューで確かめるのが セキュアプログラミングの実践です。IPAは「セキュア・プログラミング講座」や 「安全なウェブサイトの作り方」で、脆弱性ごとの書き方の注意点をまとめています。 リリース後に見つかった脆弱性は、修正・再テスト・再配布と手戻りが大きくなります。
混同しやすいものとの違い
| 用語 | 何をするか | いつ |
|---|---|---|
| セキュアプログラミング | 欠陥を作り込まないように書く | 開発中 |
| ペネトレーションテスト | 疑似攻撃で侵入できるかを確かめる | 完成後 |
| WAF | 攻撃とみられる通信を手前で遮断する | 運用中 |
| 難読化 | コードを読みにくくして解析を妨げる | 配布前 |
検査や外側の防御は、セキュアプログラミングの代わりではなく、重ねて使うものです。 「欠陥を作らない」のか「欠陥を見つける・届かせない・隠す」のかで見分けます。