marko

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

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

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

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

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

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

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

あるいは、以下をHTMLに埋め込みます
<a href="https://www.bestpractices.dev/projects/7029"><img src="https://www.bestpractices.dev/projects/7029/badge"></a>

これらは

レベルの基準です。

または

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

品質 13/13 ●

作業ビルドシステム

Criterion [build]
適合

不適合

該当なし

?

プロジェクトによって作成されたソフトウェアを利用するためにビルドが必要な場合、プロジェクトは、ソースコードからソフトウェアを自動的にリビルドできる作業ビルドシステムを提供しなければなりません。 ^[build]
ビルドシステムは、ソフトウェアをリビルドするのに必要なアクション（およびその順序）を決定し、それらのステップを実行します。たとえば、ビルドシステムは、ソースコードをコンパイルするためにコンパイラを呼び出すことができます。実行可能ファイルがソースコードから生成される場合、ビルドシステムは、プロジェクトのソースコードを変更でき、その変更を含む更新された実行ファイルを生成できなければなりません。プロジェクトによって生成されたソフトウェアが外部ライブラリに依存する場合、ビルドシステムはそれらの外部ライブラリをビルドする必要はありません。ソースコードが変更されても、ソフトウェアを使用するためにビルドする必要がない場合、「該当なし」（N/A）を選択します。

https://github.com/marko-js/marko/blob/main/package.json contains a script build
Criterion [build_common_tools]
適合

不適合

該当なし

?

ソフトウエアをビルドするために、一般的なツールを使用することをお勧めします。 ^{[build_common_tools]}
たとえば、Maven、Ant、cmake、autotools、make、rake (Ruby)、 devtools （R）などです。
All the tools used in the build scripts at https://github.com/marko-js/marko/blob/main/package.json are well known:
```
"build": "npm exec --ws -- babel ./src --out-dir ./dist --delete-dir-on-start --copy-files --config-file ../../babel.config.js --env-name=production && npm run build:types",
"build:types": "node scripts/types-babel-types.mjs > packages/compiler/dist/types.d.ts && node scripts/types-babel-traverse.js > packages/compiler/dist/traverse.d.ts",
"publish": "ENTRY=main:npm npm run set-entry && npm run build && changeset publish && ENTRY=main:dev npm run set-entry && npm ci",
```
Criterion [build_floss_tools]
適合

不適合

該当なし

?

プロジェクトは、FLOSSツールだけを使用してビルドができるようにするべきです。 ^{[build_floss_tools]}

Tools in build script -

npm: Artistic License 2.0 babel: MIT license node: MIT license changeset: MIT license
自動テストスイート

Criterion [test]
適合

不適合

?

プロジェクトは、FLOSSとして公開されている自動テストスイートを少なくとも1つ使用する必要があります（このテストスイートは、別個のFLOSSプロジェクトとして維持される場合があります）。プロジェクトは、テストスイートの実行方法を明確に示すか文書化する必要があります（たとえば、継続的インテグレーション（CI）スクリプトを介して、またはBUILD.md、README.md、CONTRIBUTING.mdなどのファイルの文書を介して）。 ^[test]
プロジェクトでは、複数の自動化されたテストスイートを使用することができます（たとえば、迅速に実行するもの、より完全であるが特別な装置が必要なもの）。Selenium (ウェブブラウザの自動化)、Junit (JVM, Java)、RUnit (R)、testthat (R) など、多くのテストフレームワークやテスト支援システムが利用可能です。

Unit tests use Mocha.

Criterion [test_invocation]
適合

不適合

?

テストスイートは、その言語の標準的な方法で呼び出すことができるべきです。 ^{[test_invocation]}
たとえば、「make check」、「mvn test」、「rake test」（Ruby）などです。

npm run test

Criterion [test_most]
適合

不適合

?

テストスイートは、コードブランチ、入力フィールド、および機能のほとんど（または理想的にはすべて）をカバーすることが推奨されています。 ^[test_most]

89.73%

File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s ---------------------------------------|---------|----------|---------|---------|------------------- All files | 89.73 | 83.34 | 86.93 | 89.93 |

Criterion [test_continuous_integration]
適合

不適合

?

プロジェクトは、継続的インテグレーション（新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動テストが実行される）を実装することを推奨されています。 ^{[test_continuous_integration]}

Tests are run on push to the main branch. See e.g. https://github.com/marko-js/marko/actions/runs/4208297860
新機能テスト

Criterion [test_policy]
適合

不適合

?

プロジェクトは、プロジェクトで作成されたソフトウェアに主要な新機能が追加されたときに、その機能のテストを自動化されたテストスイートに追加する必要があるという一般的な方針（正式でも、正式でなくても構いません）を持っていなければなりません。 ^{[test_policy]}
開発者はテストを自動テストスイートに追加して、新しい機能を追加する必要があるというポリシーが、口頭でも（文書化されていなくても）、存在する限り、「満たしている」を選択してください。

The test coverage of 90% would be impossible if this wasn't true.

Criterion [tests_are_added]
適合

不適合

?

プロジェクトによって作成されたソフトウェアの最新の大きな変更で、テストを追加するための test_policy が守られているという証拠がプロジェクトに存在しなければなりません。 ^{[tests_are_added]}
主要な機能は、通常、リリースノートに記載されます。完璧は必要ないですが、プロジェクトによって生成されたソフトウェアに新しい主要機能が追加されたときに、自動テストスイートに実際にテストが追加されているという証拠となります。

The feature PR at https://github.com/marko-js/marko/pull/1836/files includes tests.
Criterion [tests_documented_added]
適合

不適合

?

テストを追加するこのポリシー（test_policyを参照）を変更提案に関する手順で文書化することを推奨します。 ^{[tests_documented_added]}
しかし、実際にテストが追加されている限り、非公式の規則でも許容されます。
The template for "feat:" PRs has a checklist that includes a requirement that tests be added.

`Checklist:
- [ ] I have read the CONTRIBUTING document and have signed (or will sign) the CLA.
- [ ] I have updated/added documentation affected by my changes.
- [ ] I have added tests to cover my changes.`
警告フラグ

Criterion [warnings]
適合

不適合

該当なし

?

プロジェクトは、選択した言語でこの基準を実装することができる少なくとも1つのFLOSSツールがあれば、1つまたは複数のコンパイラ警告フラグ、「安全」言語モードを使用可能にするか、分離「リンター」ツールを使用してコード品質エラーまたは共通の単純なミスを検索しなければなりません。 ^[warnings]
コンパイラ警告フラグの例には、gcc / clang "-Wall"があります。「安全」言語モードの例には、JavaScript「use strict」とperl5の「use warnings」があります。分離「リンター」ツールは、ソースコードを調べてコード品質のエラーや一般的な単純なミスを探すツールです。これらは、通常、ソースコードまたはビルド命令内で有効になります。

package.json has linting scripts:

"lint": "npm run lint:eslint && npm run lint:prettier -- -l", "lint:eslint": "eslint -f visualstudio .", "lint:prettier": "prettier \"./**/*{.ts,.js,.json,.md,.yml}\"",

Criterion [warnings_fixed]
適合

不適合

該当なし

?

プロジェクトは警告を出さなければならない。 ^{[warnings_fixed]}
これらは、警告基準の実装によって識別される警告です。プロジェクトは、警告を修正するか、ソースコード内で警告を誤検出としてマークするべきです。理想的には警告がないことがいいですが、プロジェクトはある程度の警告（通常は100行あたり1警告未満、または全体で10警告未満）を受け入れることができます。

The lint script invokes prettier to fix warnings at the level of convention.

Criterion [warnings_strict]
適合

不適合

該当なし

?

プロジェクトによって作成されたソフトウェアにある警告に、実際的な場合には、最大限に厳格になることを推奨されています。 ^{[warnings_strict]}
一部の警告は、あるプロジェクトでは効果的に有効にすることはできません。必要なのは、プロジェクトが可能な限り警告フラグを有効にするように努力しており、エラーが早期に検出されるという証拠です。

The tool used doesn't really have that feature. At least it is invoked with the -l flag to alert devs to noncormant files.

分析 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）を選択します。

CodeQL has been enabled. (As a result of this Best Practices review!)

Criterion [static_analysis_common_vulnerabilities]
適合

不適合

該当なし

?

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

The project uses CodeQL, which has this feature.

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 日以内にすべての脆弱性を修正することが要求されていることに注意してください。

Since the use of SAST has just begun as a result of this Best Practices investigation, it's too soon for a timer.

Criterion [static_analysis_often]
適合

不適合

該当なし

?

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

CodeQL in CI

動的コード分析

Criterion [dynamic_analysis]
適合

不適合

?

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

It's not OK that this is unmet. Implementing this is a work item for the future.

Criterion [dynamic_analysis_unsafe]
適合

不適合

該当なし

?

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

The software uses only HTML, CSS, and Javascript.

Criterion [dynamic_analysis_enable_assertions]
適合

不適合

?

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

As I understand assertions, they are a C thing. The project is Javascript.

The project doesn't yet use a DAST tool. There should be an N/A field for this case.

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を使用して重大度を自ら計算することができます。

The project doesn't yet use a DAST tool.

このデータは、Creative Commons Attribution version 3.0以降のライセンス（CC-BY-3.0 +）のもとで利用できます。すべての人がデータを自由に共有および適応できますが、適切にクレジットを入れる必要があります。 Lucas GonzeとOpenSSFベストプラクティスバッジ貢献者のクレジットを入れてください。

プロジェクトバッジ登録の所有者： Lucas Gonze.
エントリの作成日時 2023-02-16 00:46:08 UTC、 最終更新日 2023-04-13 20:38:26 UTC

もどる

marko

基本的情報 13/13 ●

識別情報

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

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

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

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テストスイート

新機能テスト

警告フラグ

セキュリティ 14/16 ●

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

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

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

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

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

分析 8/8 ●

静的コード解析

動的コード分析

marko

基本的情報 13/13 ●

識別情報

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

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

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

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テスト スイート

新機能テスト

警告フラグ

セキュリティ 14/16 ●

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

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

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

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

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

分析 8/8 ●

静的コード解析

動的コード分析

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

自動テストスイート