PerspectiveGraph

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。

バッジステータスの埋め込み方法は次のとおりです。

バッジステータスを表示するには、あなたのプロジェクトのマークダウンファイルに以下を埋め込みます

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13828/badge)](https://www.bestpractices.dev/projects/13828)

あるいは、以下をHTMLに埋め込みます

<a href="https://www.bestpractices.dev/projects/13828"><img src="https://www.bestpractices.dev/projects/13828/badge"></a>

これらは

レベルの基準です。

または

レベル基準を表示することもできます。

Baseline Series: ベースラインレベル1 ベースラインレベル2 ベースラインレベル3

分析 8/8 ●

静的コード解析

Criterion [static_analysis]
適合

不適合

該当なし

?

選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも1つの静的コード分析ツール（コンパイラの警告と「安全な」言語モード以外）を、ソフトウェアの主要な製品リリースの提案に、リリース前に適用する必要があります。 ^{[static_analysis]}
静的コード解析ツールは、ソフトウェアコードを実行せずに特定の入力を用いて（ソースコード、中間コード、または実行可能ファイルとして）調べます。この基準のために、コンパイラの警告と「安全な」言語モードは、静的コード解析ツールとしてカウントされません（これらは通常、速度が重要なため深い解析を行いません）。このような静的コード解析ツールの例には、cppcheck (C, C++)、clang静的解析 (C, C++)、SpotBugs (Java)、FindBugs (Java) (FindSecurityBugsを含む)、PMD (Java)、Brakeman (Ruby on Rails)、lintr (R)、goodpractice (R), Coverity Quality Analyzer、SonarQube、 Codacyおよび HP Enterprise Fortify Static Code Analyzer.大きなツールのリストは、静的コード解析のためのWikipediaツール一覧, 静的コード解析に関するOWASP情報、 NISTソースコードセキュリティアナライザのリスト、およびウィーラーの静的解析ツール一覧などがあります。使用する実装言語で使用できるFLOSS静的解析ツールがない場合は、「該当なし」（N/A）を選択します。

Six static analysis tools run on every push and pull request, well beyond compiler warnings:

staticcheck, which on introduction found real defects that go vet does not see
gosec, security-focused SAST
CodeQL, semantic taint analysis
govulncheck, which reports reachable vulnerable code paths rather than merely vulnerable versions
gitleaks, secret scanning across the full history
ESLint and tsc for the dashboard
There is also a repository-specific gate: a test holds every configuration key the backend reads to all three deployment surfaces, so a key that is settable in one place and silently ignored in another fails the build.

https://github.com/luiacuaniello/perspectivegraph/blob/main/.github/workflows/ci.yml

Criterion [static_analysis_common_vulnerabilities]
適合

不適合

該当なし

?

static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 ^{[static_analysis_common_vulnerabilities]}
一般的な脆弱性を探すために特別に設計された静的解析ツールは、それらを見つける可能性が高いです。つまり、静的ツールを使用すると、通常は問題を見つけるのに役立ちますので、利用を提案しますが、「合格」レベルのバッジには要求しません。

Two of the tools are specifically vulnerability-oriented. gosec carries rules for the common Go classes: command and SQL injection, path traversal, weak cryptography, insecure randomness, unhandled errors. CodeQL performs dataflow taint tracking for the OWASP-style classes, following untrusted input to sensitive sinks across function boundaries. govulncheck goes further than a version comparison, reporting only vulnerabilities whose affected code the binary actually reaches.

Criterion [static_analysis_fixed]
適合

不適合

該当なし

?

静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。 ^{[static_analysis_fixed]}
Common Vulnerability Scoring System (CVSS)の基本的な定性的なスコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。CVSS のバージョン 2.0 から 3.1 では、これは CVSS のスコア 4.0 以上に相当します。プロジェクトは、広く利用されている脆弱性データベース（国家脆弱性データベースなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。また、脆弱性が公開された時点で計算入力が公開されている場合には、脆弱性が公開された時点でのCVSSの最新バージョンを用いて深刻度を計算することもできます。基準 vulnerabilities_fixed_60_days では、公開後 60 日以内にすべての脆弱性を修正することが要求されていることに注意してください。

Findings are fixed or justified inline, never suppressed globally. CONTRIBUTING.md forbids blanket excludes, so every suppression is a // #nosec Gxxx -- why it's safe comment at the call site where a reviewer will see it.

Two concrete cases. gosec raised G703 (path traversal via taint analysis) on the code that reads a mounted secret; it was reviewed, judged a false positive for that context (the path comes from an environment variable, and anyone who can set the process environment already owns it), and annotated with that reasoning rather than excluded. staticcheck raised ST1018 on a literal U+202E character in a test file, a Trojan Source pattern, which was replaced with an escape sequence.

All six tools currently report zero findings.

Criterion [static_analysis_often]
適合

不適合

該当なし

?

静的ソースコード解析は、コミットごと、または少なくとも毎日実行することをお勧めします。 ^{[static_analysis_often]}

On every commit, not merely daily. staticcheck, gosec, govulncheck, go vet, gitleaks, ESLint and tsc run on every push and every pull request, and a finding fails the build. CodeQL runs on push and pull request and on a weekly schedule, so newly published query packs are applied to unchanged code. Extended fuzzing runs weekly on its own schedule.

https://github.com/luiacuaniello/perspectivegraph/actions

動的コード分析

Criterion [dynamic_analysis]
適合

不適合

?

リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。 ^{[dynamic_analysis]}
動的解析ツールは、ソフトウェアを特定の入力で実行して検査します。たとえば、プロジェクトは、ファジングツール（アメリカンファジーロップなど）やウェブアプリケーションスキャナ（例： ZAP または w3af ）です。場合によっては、 OSS-Fuzz プロジェクトがプロジェクトにファズテストを適用する可能性があります。この基準のために、動的分析ツールは、様々な種類の問題を探すために何らかの方法で入力を変更するかまたは少なくとも80％のブランチカバレッジを持つ自動テストスイートである必要があります。動的解析に関するWikipediaのページとファジングに関するOWASPページで、いくつかの動的解析ツールを特定しています。解析ツールは、セキュリティの脆弱性を探すことに重点を置くことができますが、これは必須ではありません。

Three kinds of dynamic analysis run against the software as it executes.

Fuzzing: 14 Go fuzz targets against the ingest parsers, which are the boundary where attacker-influenceable bytes become graph structure. Their seed corpora execute on every go test, and a dedicated workflow runs extended campaigns weekly (Sunday, with a configurable duration on manual dispatch).

Race detection: go test -race across all 56 packages on every push. It instruments the running program to catch data races that no static tool sees.

A hostile-input battery: 11 collectors by 23 payloads (nesting bombs, invalid UTF-8, lone surrogates, 5 MB strings, path traversal, template injection, NUL bytes, bidirectional overrides), driven through the real parsers deterministically on every build. A 10-second per-payload timeout means a parser that can be stalled fails the test.

All of this runs before every release, since releases are cut from main only after CI is green.

https://github.com/luiacuaniello/perspectivegraph/blob/main/.github/workflows/fuzz.yml

Criterion [dynamic_analysis_unsafe]
適合

不適合

該当なし

?

プロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれている場合、少なくとも1つの動的ツール（たとえば、ファジーまたはウェブアプリケーションスキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 ^{[dynamic_analysis_unsafe]}
メモリの安全性の問題を検出するメカニズムの例としては、アドレスサニタイザー（ASAN）（GCCおよびLLVMで利用可能）、 Memory Sanitizer 、および valgrind が含まれます。他に使用される可能性のあるツールには、スレッドサニタイザと定義されていない動作サニタイザを参照してください。広範なアサーションも機能します。

The project produces no software in a memory-unsafe language. The backend is Go and the dashboard TypeScript, both memory-safe, and the backend is built with CGO_ENABLED=0 so no C is linked in. That also keeps the release binaries static and portable.

Fuzzing is nonetheless used extensively (14 targets), because in Go the classes it catches are panics, unbounded allocation and non-termination rather than buffer overwrites.

Criterion [dynamic_analysis_enable_assertions]
適合

不適合

?

プロジェクトでは、多くのアサーションを可能にする少なくとも一部の動的分析（テストやファジングなど）の構成を使用することをお勧めします。多くの場合、これらのアサーションは本番ビルドでは有効にしないでください。 ^{[dynamic_analysis_enable_assertions]}
この基準は、本番環境でアサーションを有効にすることを示唆するものではありません。それは完全にプロジェクトとそのユーザーが決定することです。この基準の焦点は、展開前の動的分析中の障害検出を改善することです。プロダクション環境でのアサーションの有効化は、動的分析（テストなど）中にアサーションを有効にすることとはまったく異なります。場合によっては、プロダクション環境でアサーションを有効にすることは非常に賢明ではありません（特に高整合性コンポーネントの場合）。プロダクション環境でアサーションを有効にすることには多くの議論があります。たとえば、ライブラリは呼び出し元をクラッシュさせてはなりません。ライブラリが存在するとアプリストアによる拒否が発生する可能性があります。また、プロダクション環境でアサーションをアクティブにすると、秘密鍵などの秘密データが公開される可能性があります。多くのLinuxディストリビューションではNDEBUGが定義されていないため、これらのディストリビューションのプロダクション環境ではデフォルトで C/C++ assert() が有効になります。これらの環境でのプロダクション環境では、別のアサーションメカニズムを使用するか、 NDEBUGを定義することが重要です。

The race detector is the Go analogue of an assertion-heavy build, and it is enabled exactly where the criterion suggests: -race runs across all packages in CI, and is not enabled in production builds, which are CGO_ENABLED=0 static binaries.

Tests additionally assert invariants that production code does not re-check. Two examples: the hand-rolled priority queue must agree with container/heap element by element on randomised input full of ties, and scoring output must stay byte-identical across an optimisation.

Criterion [dynamic_analysis_fixed]
適合

不適合

該当なし

?

動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 ^{[dynamic_analysis_fixed]}
動的コード分析を実行しておらず、この方法で脆弱性が見つからない場合は、「該当なし」（N/A）を選択してください。 Common Vulnerability Scoring System (CVSS)の基本的な定性的スコアが中以上の場合、脆弱性は中程度以上の重大度と見なされます。 CVSSバージョン2.0から3.1では、これは4.0以上のCVSSスコアに相当します。プロジェクトは、広く使用されている脆弱性データベース（ National Vulnerability Databaseなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを使用して使用できます。代わりに、脆弱性が公表された後に計算入力が公開された場合、プロジェクトは脆弱性の開示時に最新バージョンのCVSSを使用して重大度を自ら計算することができます。

No unfixed finding exists. The clearest example of the process working came from dynamic analysis of the GraphQL cost guard. A purpose-built probe timed the guard against a 1.2 KB document of non-cyclic fragments and showed it running for over ten seconds before a single field resolved, which is a denial of service in the very guard meant to prevent one. It was fixed in the same session by memoising fragment costs (49 µs for the same input), and the reproduction is now a permanent test that fails if the expansion stops being linear.

Race-detector and fuzzing runs are currently clean.

ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/13828/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforcedのような簡単なURLで変更を提案できます。その方法については、自動化提案システムをご覧ください。このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。Luigi IacuanielloおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクトバッジ登録の所有者： Luigi Iacuaniello.
エントリの作成日時 2026-07-26 15:51:09 UTC、 最終更新日 2026-08-07 13:24:38 UTC 最後に2026-08-07 11:55:52 UTCにバッジ合格を達成しました。

PerspectiveGraph

基本的情報 13/13 ●

一般

基本的なプロジェクトウェブサイトのコンテンツ

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

公開されたバージョン管理ソースリポジトリ

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テストスイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

セキュリティに関する開発知識

優良な暗号手法を使用する

MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信

広く知られた脆弱性を修正

その他のセキュリティ上の課題

分析 8/8 ●

静的コード解析

動的コード分析

PerspectiveGraph

基本的情報 13/13 ●

一般

基本的なプロジェクト ウェブサイトのコンテンツ

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

公開されたバージョン管理ソースリポジトリ

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テスト スイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

セキュリティに関する開発知識

優良な暗号手法を使用する

MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信

広く知られた脆弱性を修正

その他のセキュリティ上の課題

分析 8/8 ●

静的コード解析

動的コード分析

基本的なプロジェクトウェブサイトのコンテンツ

自動テストスイート