CERT コーディングスタンダードご紹介 (OSC2017@Osaka)

セキュアなソフトウェアをつくるために……CERT コーディングスタンダードご紹介

JPCERT コーディネーションセンター情報流通対策グループリードアナリスト⼾⽥洋三

2017年1⽉28⽇(⼟)

Copyright ©2017 JPCERT/CC All rights reserved.

本⽇の話題

ü⾃⼰紹介üセキュアコーディングスタンダードって?ü中⾝を⾒てみようüコーディングスタンダードの活⽤üまとめü参考情報など

2


http://www.tomo.gr.jp/root/e9706.html

JPCERT/CC情報流通対策グループリードアナリスト⼾⽥洋三

脆弱性情報分析, セキュアコーディング普及啓発活動……に努めています

3

⾃⼰紹介


JPCERT Coordination Center

日本における情報セキュリティ対策活動の向上に取り組んでいる組織

4


過去のOSC参加履歴 (セミナーを⾏ったもの)

5

•OSC2016@Hokkaido•OWASP ASVS と Cheat Sheet(日本語版)のご紹介

•OSC2015@Hokkaido•CSRF 脆弱性とその対策について

•OSC2014@Fukuoka•Lessons (to be) Learned from Handling OpenSSL Vulnerabilities

•OSC2013@Kyoto•～ヒトの振り見て我が振り直せ～脆弱性事例に学ぶJavaセキュアコーディング

•OSC2012@Fukuoka•Androidセキュアコーディング～安全なAndroidアプリ開発のための心得～

•OSC2011@Nagoya: セキュアコーディングノススメ(JAVA編)•OSC2010@Hokkaido: あなたのコードにセキュアコーディングスタンダード•OSC2009@Fukuoka: セキュアコーディングノススメ•OSC2008@Tokyo/Spring: セキュアコーディングノススメ•OSC2007@Fukuoka: セキュアコーディングノススメ•OSC2007@Niigata: ソフトウェア脆弱性を取り巻く状況と対策•OSC2007@Kansai: ソフトウェア脆弱性情報流通のこれまでとこれから•OSC2005@Tokyo/Fall: ソフトウェア脆弱性情報流通への取り組み


JPCERT/CC の活動

重要インフラ、重要情報インフラ事業者等の特定組織向け情報発信早期警戒情報

海外のNational-CSIRTや企業内のセキュリティ対応組織の構築・運⽤⽀援CSIRT構築⽀援

脆弱性情報ハンドリングØ 未公開の脆弱性関連情報を製品開発者へ提供し、

対応依頼Ø 関係機関と連携し、国際的に情報公開⽇を調整Ø セキュアなコーディング⼿法の普及Ø 制御システムに関する脆弱性関連情報の適切な

流通

マルウエア（不正プログラム）等の攻撃⼿法の分析、解析アーティファクト分析

各種業務を円滑に⾏うための海外関係機関との連携国際連携

インシデントの予測と捕捉インシデント予防発⽣したインシデントへの対応

制御システムに関するインシデントハンドリング、情報収集・分析発信制御システムセキュリティ

⽇本シーサート協議会、フィッシング対策協議会の事務局運営等国内外関係者との連携

Ø マルウエアの接続先等の攻撃関連サイト等の閉鎖等による被害最⼩化

Ø 攻撃⼿法の分析⽀援による被害可能性の確認、拡散抑⽌

Ø 再発防⽌に向けた関係各関の情報交換及び情報共有

インシデントハンドリング（インシデント対応調整⽀援）

情報収集・分析・発信定点観測（TSUBAME）

Ø ネットワークトラフィック情報の収集分析Ø セキュリティ上の脅威情報の収集、分析、必要

とする組織への提供

6

Copyright ©2017 JPCERT/CC All rights reserved.7

JPCERT/CC の主な活動


JPCERT/CC セキュアコーディングのコンテンツ

8

www.jpcert.or.jp/securecoding/


slideshare にも講演資料やセミナコンテンツ置いてます

9

www.slideshare.net/jpcert_securecoding/presentations


セキュアコーディングスタンダードって?

10


脆弱性の数実際の数は不明脆弱性の共通識別⼦ (CVE) が割り振られたものは⽶国 NIST がデータを提供している (2015年は6488件)

11

https://nvd.nist.gov/ の statistics から


JVN: Japan Vulnerability Notes

12

https://jvn.jp/ http://jvndb.jvn.jp/


セキュアなソフトウェア開発

13

セキュアデザイン

動的コード解析

セキュアな実⾏環境

静的コード解析

デザインコーディングテスト実⾏

セキュアコーディングスタンダード

セキュアコーディングスタンダード


プログラミング⾔語Cの問題

14

C⾔語の精神:プログラマを信頼し、やりたいことができるように

⾔語仕様には未規定、未定義、処理系定義事項が存在する

⾔語仕様の詳細を知らないプログラマが未定義動作などの問題のあるコードを書き、脆弱性を作り込む

セキュアなコードを書くための道しるべ・ガイドラインが必要!


GNU coding standardshttps://www.gnu.org/prep/standards/

FLEX SDK coding conventions and best practiceshttps://sourceforge.net/adobe/flexsdk/wiki/Coding%20Conventions/

Zend Framework PHP 標準コーディング規約https://framework.zend.com/manual/2.4/en/ref/coding.standard.html

組込みソフトウェア開発向けコーディング作法ガイド[C⾔語版]https://www.ipa.go.jp/sec/publish/tn13-001.html

The NetBSD source code style guidehttp://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style?rev=HEAD

コーディングスタイル

Developer’s Guide to oracle Solaris 11 SecurityAppendix A (Secure Coding Guidelines for Developers)https://docs.oracle.com/cd/E26502_01/html/E29016/scode-1.html

などなど…

JPL Institutional Coding Standard for the C Programming Languagehttp://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

MISRA C:2012Guidelines for the Use of the C Language in Critical Systems

コーディング規約

Google Style Guideshttps://github.com/google/styleguide

ガイドラインって?

15

Programming Stylehttps://en.wikipedia.org/wiki/Programming_style


SEI CERT (セキュア)コーディングスタンダード集

https://www.securecoding.cert.org/


CERT (セキュア)コーディングスタンダード集


CERT コーディングスタンダード

18

セキュアなソフトウェアをつくるためのコーディングガイドライン集

- 攻撃可能な脆弱性を作り込まない- コードの保守性向上

= プログラマが理解しやすい= 移植性向上

対象:ソフトウェア開発やメンテナンスに携わる⼈々


- コンパイラ作者向けでなくCプログラマ向け

-第⼀⽬的: 今後の開発に役⽴つガイドライン=第⼆⽬的: 既存のレガシーコードのメンテナンスに役⽴つ

ガイドライン

- できるだけOSや実⾏環境に依存しない= 環境依存な⽅法に⾔及する場合、おもに

POSIX(Unix)およびWindowsにおけるコード例を⽰す

- C99およびC11に基づく

19

CERT C コーディングスタンダード


開発に携わる⼈々

20

CERT Secure Coding Initiative言語仕様関係者、コンパイラベンダ、開発者など、多様な人々を含むコミュニティベースでの議論と開発

CMU/SEI CERT division のWikiサイト上で開発中https://www.securecoding.cert.org/

実際に発⾒された脆弱性を反映商⽤ソースコード解析ツールも対応

Coverity, Fortify, Klocwork, LDRA, ...

JPCERT/CC にて⽇本語版を提供https://www.jpcert.or.jp/sc-rules/https://www.jpcert.or.jp/java-rules/


セキュアコーディングスタンダード⽇本語版

21


セキュアコーディングスタンダード⽇本語版

22


中⾝を⾒てみよう

23


中⾝を⾒てみようC コーディングスタンダード日本語版(https://www.jpcert.or.jp/sc-rules/)

•カテゴリ一覧•ルールとレコメンデーション•各ページの構成(説明, 違反コード, 適合コード, リスク評価, 参考情報)

C コーディングスタンダードカテゴリ: 16ガイドライン: 302 (必須118, 推奨184)

24


中⾝を⾒てみよう: カテゴリ⼀覧01.プリプロセッサ(PRE)02. 宣言と初期化(DCL)03. 式(EXP)04. 整数(INT)05. 浮動小数点(FLP)06. 配列(ARR)07. 文字と文字列(STR)08. メモリ管理(MEM)09. 入出力(FIO)10. 環境(ENV)11. シグナル(SIG)12. エラー処理(ERR)13. Application Programming Interface(API)14. 並行性(CON)49. 雑則(MSC)50. POSIX(POS)

内容に応じて分類

25


☆ レコメンデーション (推奨)

☆ ルール (必須)中⾝を⾒てみよう: 「ルール」と「レコメンデーション」

○ コーディング作法への違反が、攻撃可能な脆弱性を生み出すセキュリティ上の欠陥につながる可能性がある。

○ コーディング作法へ適合しているかどうかを、自動解析、形式的方法、手作業によるソースコード検査などを通じて確認することができる。

https://www.jpcert.or.jp/sc-rules/00.introduction.html

○ コーディング作法を適用することで、システムのセキュリティが高まる可能性がある。

○ コーディング作法がルールと見なされるための要件を、一つ以上満たすことができない。

26


☆ レコメンデーション (推奨)

☆ ルール (必須)中⾝を⾒てみよう: 「ルール」と「レコメンデーション」

○ コーディング作法への違反が、攻撃可能な脆弱性を生み出すセキュリティ上の欠陥につながる可能性がある。

○ コーディング作法へ適合しているかどうかを、自動解析、形式的方法、手作業によるソースコード検査などを通じて確認することができる。

○ コーディング作法を適用することで、システムのセキュリティが高まる可能性がある。

○ コーディング作法がルールと見なされるための要件を、一つ以上満たすことができない。

セキュリティを確保するために必ず適用すべきもの

○ スタンダード準拠の必須項目○ 適合していることを確認できる

セキュリティを向上させるガイドライン、提案

○ スタンダード準拠には必須ではない○ 必ずしも攻撃につながらない、適合の確認が難しい、など


27


中⾝を⾒てみよう: 各ガイドラインの構成(1)

識別番号とタイトル

説明違反コード適合コード(例外)リスク評価参考情報

カテゴリ名番号-C 例: INT01-C, EXP32-C

C スタンダードの場合、0〜29までの番号はレコメンデーション30以降の番号はルール

28


中⾝を⾒てみよう: 各ガイドラインの構成(2)識別番号とタイトル

説明

違反コード

適合コード

(例外)

リスク評価参考情報

内容の説明「〜すべきである」「〜すべきでない」

簡単な違反コード例

違反コードの修正例や別の適切なアプローチのコード例など

このガイドラインにしたがう必要のない状況についての説明

29


中⾝を⾒てみよう: 各ガイドラインの構成(3)識別番号とタイトル説明違反コード適合コード例外

リスク評価

参考情報

この評価値により、準拠すべきガイドラインに優先順位をつけられる


深刻度、攻撃可能性、修正コストの観点から評価

⾔語仕様の関連セクション、解説記事、関連するCWE番号など

30


例: MEM30-C: 解放済みメモリにアクセスしない (1/8)

算術演算のオペランドとしての逆参照または動作、型のキャスト、または代入の右手側としてのポインタの使用を含め、動的記憶域に割り当てられていたブロックがメモリ管理関数によって解放された後、解放されたメモリを指すポインタは評価しない。

C 標準によれば、free() または realloc()関数の呼び出しによって解放された領域を指すポインタの値を使用しているプログラム動作は未定義である。 (附属書 J 「未定義の動作」の 177 を参照。)

解放されたメモリを指すポインタの値を読み取ると、ポインタ値は不定であり、さらにトラップ表現の場合があるため、未定義の動作となる。後者の場合、それによってハードウェアトラップを引き起こす可能性がある。

一度解放されたメモリにアクセスすると、ヒープの管理に使用されているデータ構造を壊す可能性がある。割り当てを解除されたメモリを参照するポインタはダングリングポインタと呼ばれる。ダングリングポインタにアクセスすると、攻撃可能な脆弱性を引き起こす可能性がある。

メモリが解放されても、メモリの内容がそのまま残りアクセス可能な場合がある。これは、解放されたブロックをいつ再割り当てし再使用するかは、メモリマネージャが決定するためである。解放された位置にあるデータは有効であるかのように見えるかもしれない。しかし、このデータは予期せず変更される可能性があり、意図しないプログラム動作を引き起こしうる。そのため、一度解放したメモリへの書き込みや、メモリの読み取りを行わないことを保証する必要がある。

31



違反コードK & R [Kernighan 1988]（邦題：『プログラミング言語C』）のこの例では、リンクリストから項目を削除する誤った手法と正しい手法の両方を示している。誤った手法は、p->nextが参照される前に p を解放しており、p->nextはすでに解放されたメモリを読み取るため、本の中でも明白に誤りだと記されている。

for (p = head; p != NULL; p = p->next)free(p);

適合コードK & Rは正しい解決法も示している。このエラーを修正するために、p を解放する前に p->nextへの参照を qに格納している。

for (p = head; p != NULL; p = q) {q = p->next;free(p);

}head = NULL;

32



違反コード以下のコード例では、buffが解放されたあとに、buffへの書き込みが行われている。この手の脆弱性の悪用は容易であり、脆弱なプロセスの権限で任意のコードが実行される可能性があるが、この例ほどわかりやすいことはまれである。一般に、割り当てと解放が行われる場所は遠く離れており、問題に気付き原因をつきとめることはむずかしい。

int main(int argc, const char *argv[]) {char *buff;buff = (char *)malloc(BUFFERSIZE);if (!buff) {

/* エラー条件の処理 */}/* ... */free(buff);/* ... */strncpy(buff, argv[1], BUFFERSIZE-1);

}

33



適合コード以下の解決法では、メモリが不要になってからメモリを解放している。

int main(int argc, const char *argv[]) {char *buff;buff = (char *)malloc(BUFFERSIZE);if (!buff) {

/* エラー条件の処理 */}/* ... */strncpy(buff, argv[1], BUFFERSIZE-1);/* ... */free(buff);

}

34



違反コードlibwmfバージョン 0.2.8.4 の以下のコード例 (CVE-2009-1364) では、返り値 gdRealloc (im->clip->listが指す領域を再割り当てするシンプルなラップアラウンド realloc) は moreに設定される。ただし、im->clip->listの値は後から直接コードで使用され、C 標準では reallocが指す領域を移動した場合、元の領域は解放されると規定されている。攻撃者は、再割り当て (十分な im->clip->count) を強制的に実行し、解放されたメモリにアクセスすることで任意のコードを実行できる [xorl 2009]。

void gdClipSetAdd(gdImagePtr im,gdClipRectanglePtr rect) {gdClipRectanglePtr more;if (im->clip == 0) {

...}if (im->clip->count == im->clip->max) {

more = gdRealloc (im->clip->list,(im->clip->max + 8) * sizeof (gdClipRectangle));if (more == 0) return; // if the realloc fails, then we have not lost the im->clip->list valueim->clip->max += 8;

}im->clip->list[im->clip->count] = (*rect);im->clip->count++;

35



適合コード適合コードでは、realloc を呼び出した後、im->clip->list を値 moreに再割り当てする。

void gdClipSetAdd(gdImagePtr im,gdClipRectanglePtr rect) {gdClipRectanglePtr more;if (im->clip == 0) {

...}if (im->clip->count == im->clip->max) {

more = gdRealloc (im->clip->list,(im->clip->max + 8) * sizeof (gdClipRectangle));if (more == 0) return;im->clip->max += 8;im->clip->list = more;

}im->clip->list[im->clip->count] = (*rect);im->clip->count++;

36



解放済みのメモリを読み取ると、プログラムの異常終了やサービス運用妨害(DoS)攻撃を引き起こす可能性がある。解放済みのメモリに書き込むと、バッファオーバーフローや、脆弱なプロセスの権限を使った任意のコード実行につながる可能性がある。

ルール深刻度可能性修正コスト優先度レベル

MEM30-C 高高中 P18 L1

自動検出

ツールバージョンチェッカー説明

Compass/ROSE

Coverity 6.5 USE_AFTER_FREEメモリが複数回解放されるか、または解放されたポインタの対象に対して読み取り/書き込みを⾏う特定の事例を検出できる。

Fortify SCA 5.0

Klocwork 9.1

UFM.DEREF.MIGHTUFM.DEREF.MUSTUFM.RETURN.MIGHTUFM.RETURN.MUSTUFM.USE.MIGHTUFM.USE.MUST

LDRA tool suite 8.5.4 51 D 実装済み

splint 3.1.1

リスク評価

37



関連するガイドライン

CERT C++ Secure Coding Standard MEM30-CPP. Do not access freed memory

ISO/IEC TR 24772:2013 Dangling References to Stack Frames [DCM]Dangling Reference to Heap [XYK]

ISO/IEC TS 17961 (ドラフト) Accessing freed memory [accfree]

MISRA-C Rule 17.6

MITRE CWE CWE-416, Use after free

参考資料

[Kernighan 1988] Section 7.8.5, "Storage Management"

[OWASP Freed Memory]

[Seacord 2013] Chapter 4, "Dynamic Memory Management"

[Viega 2005] Section 5.2.19, "Using Freed Memory"

[xorl 2009] CVE-2009-1364: LibWMF Pointer Use after free()

翻訳元これは以下のページを翻訳したものです。MEM30-C. Do not access freed memory (revision 122)

38


中⾝を⾒てみよう(Javaコーディングスタンダード)

Java コーディングスタンダード日本語版(https://www.jpcert.or.jp/sc-rules/)

•カテゴリ一覧•ルールとレコメンデーション•各ページの構成(説明, 違反コード, 適合コード, リスク評価, 参考情報)

Java コーディングスタンダードカテゴリ数: 17ルール数: 158 (レコメンデーションは未訳)

39


中⾝を⾒てみよう: カテゴリ⼀覧(Javaコーディングスタンダード)

00. 入力値検査とデータの無害化(IDS)01. 宣言と初期化(DCL)02. 式(EXP)03. 数値型とその操作(NUM)04. オブジェクト指向(OBJ)05. メソッド(MET)06. 例外時の動作(ERR)07. 可視性とアトミック性(VNA)08. ロック(LCK)09. スレッドAPI(THI)10. スレッドプール(TPS)11. スレッドの安全性に関する雑則(TSM)12. 入出力(FIO)13. シリアライズ(SER)14. プラットフォームのセキュリティ(SEC)15. 実行環境(ENV)49. 雑則(MSC)

内容に応じて分類

40


GNU Coding Standards との⽐較

41

GNU Coding Standards- GNUシステムをクリーンに、⼀貫性のある、

インストールしやすいものにするため("to make the GNU system clean, consistent, and easy to install")

- ポータブルで頑丈で⾼信頼性なプログラムを書くためのガイドにもなる("also be read as a guide to writing portable, robust, and reliable programs")

CERT C セキュアコーディングスタンダード- C を使う全ての⼈のために- 攻撃に使われるような脆弱性を作り込まないようにするためのガイドライン

ポータブル、頑丈、⾼信頼性と重なる部分あり


MISRA-C:2012 との⽐較

42

MISRA-C:2012(Guidelines for the use of the C language in critical systems)- 組み込みや重要インフラ系システムにおけるC使⽤に関するガイドライン- 安全性、移植性、信頼性向上のため- C90およびC99に基づく

CERT C セキュアコーディングスタンダード- OSや実⾏環境などを特定せずC を使う全ての⼈のために- 脆弱性をつくりこまないように → 安全性、移植性、信頼性と重なる- C99およびC11に基づく

MISRA-C:2012ルール数: 143(義務10, 必須101, 推奨32)

CERT C コーディングスタンダードカテゴリ数: 17ルール数: 306 (必要120, 推奨186)


ソースコード解析ツール (C)https://www.securecoding.cert.org/confluence/x/uoFuCQ

43


ソースコード解析ツール (Java)https://www.securecoding.cert.org/confluence/x/xIJuCQ

44


CERT C と国際標準化ISO/IEC TS 17961C Secure Coding Rules—CERT C コーディングスタンダードをベースに国際標準化され

たセキュアコーディングルール集ルール：検出(diagnose)されるべきコーディング

— 例: “Accessing an object through a pointer to an incompatible type (other than unsigned char) shall be diagnosed”

根拠(rationale)：⾔語仕様書の典拠違反コード例

45

JTC1/SC22/WG14 - C

コンパイルは通っても安全な動作が保証されないケースをまとめた⾔語仕様書の副読本

参考: ISO/IEC TS 17961 C Secure Coding Rules(https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=140705863)

参考: Secure Coding Validation Suite (https://github.com/SEI-CERT/scvs)


コーディングスタンダードの活⽤

46


セキュアコーディングスタンダードの活⽤

●セキュアコーディングの学習に

●開発チーム内の認識共有

●製品のセキュリティ関連仕様の明確化

47


活⽤: セキュアコーディングの学習資料として(1)

セキュアコーディングを学ぶ教材として使う●「セキュアコーディングってなに?」●「こんなトピック知ってる?」

社内での研修や勉強会の教材に●違反コード・適合コードでクイズ形式

48



コード解析ツールを活⽤するための補助資料検出結果を理解するために

ツールの説明よりも分かりやすく別の観点での説明

49



コード解析ツールを活⽤するための補助資料検出結果の対応を検討するために

どのように修正すべきなの?ホントに修正すべきなの?

セカンドオピニオンとして...

50


活⽤: 開発チーム内の認識共有(1)

コーディングの良し悪しの判断基準

セキュリティ確保のための⽬標を具体化●「ルールXXとYYには準拠しよう! 」

セキュリティ品質向上の⼿段として活⽤

51


活⽤: 開発チーム内の認識共有(2)

⾃社のコーディング規約の⼟台として

●既存の内容に不⾜がないかチェック●命名規則やコーディングスタイルなどは独⾃に決める必要がある

52


活⽤: セキュリティ仕様明確化(1)

品質チェックの具体的な項⽬の洗い出しに

⼊⼒値チェックはきちんとやってるか⾮推奨な関数使ってないか可搬性の問題はないか......

53



要求仕様として提⽰●コーディング規約XXを遵守すること●レベルL1のルールを遵守すること●レベルL2までのルールを全て遵守することなど

あいまいだったセキュリティ⾯の仕様の内容について、より明確な基準で議論できる

54



実装仕様として提⽰●コーディング規約XXを遵守してます●レベルL1のルールを遵守してます●レベルL2までのルールを全て遵守してますなど

あいまいだったセキュリティ⾯の仕様の内容について、より明確な基準で議論できる

55


まとめ

56

SEI CERT コーディングスタンダード—セキュアなソフトウェアをつくるためのコーディング

ガイドライン集—C, Java, C++, Perl, Android

—解説、違反コード例、適合コード例想定読者層: ソフトウェア開発やメンテナンスに携わる⼈々⼀般⽇本語版もあるから活⽤してね!—https://www.jpcert.or.jp/sc-rules/—https://www.jpcert.or.jp/java-rules/


おまけ: おすすめリーディングマップ04. 整数(INT)07. 文字と文字列(STR)

05. 浮動小数点(FLP)11. シグナル(SIG)12. エラー処理(ERR)13. (API) 50. POSIX(POS)

06. 配列(ARR)08. メモリ管理(MEM)

基本データ型についてしっかりおさえよう!

01. プリプロセッサ(PRE)02. 宣言と初期化(DCL)03. 式(EXP)10. 環境(ENV)09. 入出力(FIO)

重要なデータ構造として、配列と動的メモリ管理を

チェック!

57


コーディングスタンダードの協⼒者募集中!CERTコーディングスタンダード⽇本語版の整備に協⼒してくれる⽅を求めています。—Java, Android, C, C++, ……—既存の⽇本語へのコメント、改善案—英語原⽂へのコメント、改善案—さらに編集も…

58


関連リソース

59

CERT C コーディングスタンダード(https://www.jpcert.or.jp/sc-rules/)

Java コーディングスタンダード CERT/Oracle 版(https://www.jpcert.or.jp/sc-rules/)

CERT Secure Coding Standards(https://www.securecoding.cert.org/)

CERT/CC Secure Coding(https://www.cert.org/secure-coding/)


関連リソース【改訂版】組込みソフトウェア開発向けコーディング作法ガイド［C言語版］(http://www.seshop.com/product/detail/7950/)

MISRA-C:2004 ガイドブック(http://www.sessame.jp/workinggroup/WorkingGroup3/MISRA-C_GuigeBook2004.htm)

組込み現場の「C」プログラミング標準コーディングガイドライン(http://gihyo.jp/book/2007/978-4-7741-3254-9)

60


セキュアコーディングに関するお問合せ、インシデント対応のご依頼は

61

JPCERTコーディネーションセンター̶Tel：03-3518-4600̶https://www.jpcert.or.jp/

セキュアコーディングに関するお問い合わせ̶Email：[email protected]̶https://www.jpcert.or.jp/securecoding/

インシデントの報告̶Email：[email protected]̶https://www.jpcert.or.jp/form/

Internet

CERT コーディングスタンダードご紹介 (OSC2017@Osaka)