アプリケーションのためのセーフティ コーディング テクニック

開発組織の成熟度にもよりますが、欠陥のハンティングと修正は開発時間の最大80%を占める可能性があります。これにより、コードの品質が大きな懸念事項であるという明らかな結論が得られます。なぜ欠陥を全て避け、デバッグに費やす時間を減らすことができないのでしょうか？

余談ですが、私たちは今でもソフトウェアの「バグ」やデバッグという概念を使っていますが、この用語はハーバード大学の機械式コンピュータで蛾がリレーに止まっていたことに由来しており、この出来事はコンピュータ史上初のシステムの「バグ」あるいは欠陥として記録されています。

同じ間違いを何度も繰り返す

Web、アプリ、デスクトップ、または組み込みの開発者は、同じ種類の間違いをソースコードに何度も誤って挿入する傾向があることがよく知られています。 この結論は、NASA、ベル研究所、MITREなど、調査と研究を行っているさまざまな相応な機関から報告されています。 陥りやすい誤りの一般的な例としては、C ++コード（またはCコード）でのメモリ開放なしのメモリ割り当てや、プロトタイピングなしで使用される関数などがあります。コンパイル時には厳密な型チェックが行われません。 この調査の成果物は、危険で悪いコーディング動作を特定するベストプログラミングプラクティスまたは推奨プログラミングプラクティスのリストです。

よくある間違いとそれらを回避する方法に基づいてコード品質を改善するために利用できる多くのガイドラインとコーディングプラクティスがあります。 いくつかのテクニックとプラクティスは、特に自動車、医療、鉄道などの重要な業界で、アプリケーションのコードのセーフティとセキュリティを確保するために、よく知られている標準規格（MISRA-CやCERT-Cなど）になりました。 IEC 61508 [2]、EN 50128 [3]、ISO 26262 [4]などの機能安全規格では、標準規格に準拠するために静的解析およびランタイム解析の使用を推奨しています（安全度水準（SIL）または自動車安全水準（ASIL）によっては強く推奨されています。） セーフティクリティカルシステムの欠陥は、人命の損失や環境損害などの深刻な結果につながる可能性があります。

信頼性に焦点を当てる

セーフティコーディング技術は、コード品質、コードセーフティ、およびコードセキュリティの組み合わせです。 コードセーフティはソフトウェアの信頼性に重点を置いていますが、コードのセキュリティは不要なアクティビティの防止と攻撃に対するシステムの安全性の維持に重点を置いており、どちらもすべての堅実なアプリケーションの基盤であるコード品質に大きく依存しています。

セーフティコーディング技術と標準規格は、必要な信頼性を確保するためにソフトウェアセーフティを推進しますが、ソースコードの可読性と保守性を強化することも重要です。 より効率的で読みやすいコードは、将来有効な欠陥の少ないソースコードを意味し、コードの再利用を可能にします。

MISRA Cは、一般的な陥りやすい誤りや脆弱性を回避するための最も確立されたソフトウェア開発標準規格の1つですが、組み込みアプリケーションに強く推奨されるCWEやCERT-Cコーディング標準などの追加のガイドラインがあります。 コーディング標準についてもう少し詳しく見ていきましょう。

MISRAC標準規格

MISRA Cは、Motor Industry Software Reliability Association によって開発されました。 その目的は、組み込みシステム、特にISO Cでプログラムされたシステムのコンテキストで、コードのセーフティ、移植性、および信頼性を促進することです。

MISRA C標準の初版である「Guidelines for the use of the C language in vehicle based software」は、1998年に作成され、正式にはMISRA-C：1998として知られています。 さらにルールを追加するために、2004年と2012年に更新されました。 C ++ 2003に基づくMISRAC ++ 2008標準もあります。最近、MISRA C：2012、修正1は、ISOCセキュアガイドラインによって強調されたセキュリティ上の懸念に焦点を当てた14の追加ルールを追加します。 これらのルールのいくつかは、信頼できないデータの使用に関連する特定の問題に対処します。これは、多くの組み込みアプリケーションでよく知られているセキュリティの脆弱性です。

MISRAは、コードを正式なビルドにチェックする前に問題を見つけるのに役立ちます。この方法でバグを見つけると、欠陥が発生しなかったことになります。 MISRAルールは、セーフティと信頼性を念頭に置いて設計されていますが、コードを他のツールやアーキテクチャに移植しやすくしています。

CWE と CERT C/C++

CWE(Common Weakness Enumeration)は、コミュニティで開発されたソフトウェアの弱点タイプの辞書です。 CWEは、ソフトウェアの弱点をよりよく理解して管理し、それらを見つけることができる効率的なソフトウェアセキュリティツールとサービスを有効にするために、統合された測定可能な一連のソフトウェアの弱点を提供します。

CERT C / C ++セキュアコーディング標準は、C / C ++プログラミング言語でのセキュアコーディングのルールと推奨事項を提供する、Computer Emergency Response Team（CERT）によって公開された標準規格です。

セーフティコーディングテクニックの実施

一般的な推奨事項として、すべての組み込みアプリケーションは、少なくともCWEおよびCERT C / C ++標準に準拠する必要があります。 MISRA Cは、セーフティクリティカルシステムに必須です。

同じ概念に従うと、実行時には、算術問題、バッファオーバーフロー、境界の問題、ヒープの整合性、およびメモリリークの影響を受ける可能性があります。 このようなエラーは、潜在的なエラーが発生する可能性のあるすべての場所に特定のインストルメンテーションコードまたはアサートを挿入することで検出できます。 ただし、手動で命令を追加して状態を確認し、実行時に問題を報告することは、非常に時間のかかる作業です。

すべてのガイドラインと標準を適用するということは、コードをインストルメント化することに加えて、約700のルールと要件に準拠する必要があることを意味します。 では、どのようにしてセーフティコーディングテクニックを実施し、すべてのルールに対応できるでしょうか。

自動化されたツールの使用

ソフトウェアの品質、セーフティ、セキュリティを強化する最善の方法は、自動化されたツールを使用することです。 これは、機能安全の認証を受け、自動化された静的解析およびランタイム解析と組み合わせた高品質のコンパイラとリンカを使用することで実現できます。

コンパイラとリンカは、C（ISO / IEC 9899：2018）やC ++（ISO / IEC 14882、C ++ 17リビジョンのC ++として知られる）などの最新のプログラミング言語をサポートして、疑わしい状況または構文の弱点に対して警告を生成する必要があります 。例えば 評価の順序がアプリケーションのロジックに影響を与える可能性のある揮発性メモリアクセスに対しての警告。

警告は最初のパスの静的解析チェックであり、特に機能安全設定では無視しないでください。 すべての警告をエラーとして扱うようにコンパイラ設定を変更して、警告をエラーに変えることをお勧めします。 これにより、すべての問題が真の問題として処理されるため、開発者はコード内のすべての曖昧さを修正することを強いられます。

静的解析ツールは、コードの欠陥の最も一般的な原因を見つけるのに役立ちますが、開発者がコードを書こうとしているとき、特に何か機能させるための足場となるコードを作成している時に、考えたり心配したりしない傾向のある問題を見つけるのにも役立ちます。 これらのタイプのツールは、コーディング標準を適用するため、より優れたコードの開発に役立ちます。 さらに、実行時にのみ現れる欠陥をキャッチしてトリガする動的または実行時解析ツールがあります。 ランタイム解析ツールは、ソフトウェアデバッガでプログラムを実行しているときに、コード内の実際のエラーと潜在的なエラーを見つけることができます。

したがって、システムに存在する可能性のあるすべての欠陥を調べる場合、静的解析でいくつかの欠陥を見つけ、ランタイム解析で他の欠陥を見つけることが適しています。 検出は重複する場合もありますが、ある欠陥が検出できるのは一方のドメインまたは他方のドメインのみである場合もあります。 可能な限り最高のコード解析を行うには、両解析を組み合わせて使用し、高品質のビルドツールと統合して使用する必要があります。 以下のマトリックスは、さまざまなツールを組み合わせた場合の完全な欠陥カバレッジを最もよく表しています。

抜け道を見つける

この効果は、ドイツのBielefeld大学から撮影した下の写真で最もよく説明できます[5]。 この写真は匿名の寄稿者によって撮影され、2005年に広く配布されました。

システムを破壊する最も簡単な方法は、多くの場合、システムを打ち負かすのではなく、抜け道を考えることです。 これは主に、セキュアでないコーディングプラクティスに関連するソフトウェアの脆弱性に当てはまります。 上の図は、これに非常によく似ています。ゲートは推奨に従って配置されており、仕様に従って適切に機能しています。 ただし、セキュリティ対策は簡単に回避され、ランタイム分析ツール（この場合は雪）が設置されるまで、セキュリティシステムの欠陥を見つけることはおそらく困難でした。 潜在的な抜け道がないかコードをスキャンする自動ランタイム解析は、これらのタイプの問題を検出するための優れた方法です。

この場合、安全性の脆弱性はハードウェアすなわちコンクリートボラードの設置によって修正されました。2020年のGoogleストリートビュー[6]：

コーディング標準は、コードの将来性を保証し、再利用を容易にするのに役立ちます。 これは、コードの品質がコードの再利用性に影響を与えることを意味します。これは、優秀な組織が新製品を開発する際の文化です。 セーフティコーディング技術を実施することは好循環であり、それは私たちの前提を再確認します：すべては単にコード品質から始まります。

This article is written by Rafael Taubinger, our Technical Marketing Specialist.

References

[1] Hopper (1978) p. 16.
[2] https://www.iec.ch/functionalsafety/standards/page2.htm
[3] https://standards.globalspec.com/std/14256883/EN%2050128
[4] https://www.iso.org/standard/43464.html
[5] https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices?focusedCommentId=88044413
[6]https://www.google.cz/maps/@52.0366688,8.4912691,3a,75y,35.86h,98.92t/data
=!3m6!1e1!3m4!1soRzmyEEoGqUoVhlyGWmyEw!2e0!7i13312!8i6656