From c0d3c729e40c1a41918397311a94bcab9428b060 Mon Sep 17 00:00:00 2001 From: Avishay Balter Date: Fri, 9 Aug 2024 11:54:32 +0100 Subject: [PATCH] lint Signed-off-by: Avishay Balter --- docs/memory-safety-continuum.md | 64 ++++++++++++++++----------------- 1 file changed, 31 insertions(+), 33 deletions(-) diff --git a/docs/memory-safety-continuum.md b/docs/memory-safety-continuum.md index 1290d1a..637caa9 100644 --- a/docs/memory-safety-continuum.md +++ b/docs/memory-safety-continuum.md @@ -20,7 +20,7 @@ This continuum, from "most safe" to "least safe", is intended to help you define ### Memory safe by default language (such as Rust, Go, Python, Java, JavaScript, C#) -- Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code as well as in all your dependencies' code ([examples](#Using-a-memory-safe-by-default-language-with-developer-best-practices-and-automated-tooling-to-check-for-memory-safety-in-your-code-as-well-as-in-all-dependencies-code)) +- Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code as well as in all your dependencies' code ([examples](#using-a-memory-safe-by-default-language-with-developer-best-practices-and-automated-tooling-to-check-for-memory-safety-in-your-code-as-well-as-in-all-dependencies-code)) - Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code only ([examples](#using-a-memory-safe-by-default-language-with-developer-best-practices-language-processors-post-processors-etc-and-automated-tooling-to-check-for-memory-safety-in-your-code)) - Following the language's best practices that include using language processors without any additional tooling ([examples](#using-a-memory-safe-by-default-language-with-developer-best-practices-and-language-processors-post-processors-etc-but-no-automated-tooling)) - Not following the language's best practices ([examples](#using-a-memory-safe-by-default-language-without-developer-best-practices)) @@ -30,42 +30,42 @@ This continuum, from "most safe" to "least safe", is intended to help you define - Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code as well as in all your dependencies' code ([examples](#using-a-non-memory-safe-by-default-language-with-developer-best-practices-and-automated-tooling-to-check-for-memory-safety-in-your-code-as-well-as-in-all-your-dependencies-code)) - Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code only ([examples](#using-a-non-memory-safe-by-default-language-with-developer-best-practices-and-automated-tooling-to-check-for-memory-safety-in-your-code)) - Following the language's best practices that include using language processors without any additional tooling ([examples](#using-a-non-memory-safe-by-default-language-with-developer-best-practices-but-no-automated-tooling)) -- Not following the language's best practices ([examples](#Using-a-non-memory-safe-by-default-language-without-developer-best-practies-or-automated-tooling)) +- Not following the language's best practices ([examples](#using-a-non-memory-safe-by-default-language-without-developer-best-practies-or-automated-tooling)) ### Examples ### Using a memory safe by default language with developer best practices and automated tooling to check for memory safety in your code as well as in all dependencies' code -* Using a fuzzer such as [AFL++](https://github.com/AFLplusplus/AFLplusplus) on both your own code and third party code -* TO DO - add more examples +- Using a fuzzer such as [AFL++](https://github.com/AFLplusplus/AFLplusplus) on both your own code and third party code +- TO DO - add more examples ### Using a memory safe by default language with developer best practices, language processors, post processors etc. and automated tooling to check for memory safety in your code Examples: -* Using the [Go Data Race Detector](https://go.dev/doc/articles/race_detector) -* Using other tools such as [govulncheck, fuzzing, and vet](https://go.dev/doc/security/best-practices) when writing Go code -* Using a mutation tester such as [cargo-mutants](https://github.com/sourcefrog/cargo-mutants) -* Using [CodeQL](https://codeql.github.com/) for the [languages that CodeQL supports](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/) -* Using [DevSkim](https://github.com/microsoft/devskim) IDE extensions/language analyzers +- Using the [Go Data Race Detector](https://go.dev/doc/articles/race_detector) +- Using other tools such as [govulncheck, fuzzing, and vet](https://go.dev/doc/security/best-practices) when writing Go code +- Using a mutation tester such as [cargo-mutants](https://github.com/sourcefrog/cargo-mutants) +- Using [CodeQL](https://codeql.github.com/) for the [languages that CodeQL supports](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/) +- Using [DevSkim](https://github.com/microsoft/devskim) IDE extensions/language analyzers ### Using a memory safe by default language with developer best practices and language processors, post processors etc., but no automated tooling Examples: -* Following the [Rustnomicon](https://doc.rust-lang.org/nomicon/intro.html) careful practices when using unsafe blocks in Rust -* Following best practices (LINK NEEDED) when using the Go [unsafe](https://pkg.go.dev/unsafe#pkg-overview) package -* Following [Javascript Memory Management](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management) practices -* Ensuring [soundness](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) of unsafe Rust code +- Following the [Rustnomicon](https://doc.rust-lang.org/nomicon/intro.html) careful practices when using unsafe blocks in Rust +- Following best practices (LINK NEEDED) when using the Go [unsafe](https://pkg.go.dev/unsafe#pkg-overview) package +- Following [Javascript Memory Management](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management) practices +- Ensuring [soundness](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) of unsafe Rust code ### Using a memory safe by default language without developer best practices Examples: -* Using unsafe blocks in Rust [without assessing the entire module in which the unsafe code appears](https://github.com/ossf/Memory-Safety/issues/15#issuecomment-1847939439) -* Using the [no_mangle](https://github.com/rust-lang/rust/issues/28179) attribute in Rust -* Using compiler options which turn off some or all of the compiler's memory safety checks -* Disabling .NET's source code [Analyzers](https://learn.microsoft.com/en-gb/dotnet/fundamentals/code-analysis/overview?tabs=net-8) during build +- Using unsafe blocks in Rust [without assessing the entire module in which the unsafe code appears](https://github.com/ossf/Memory-Safety/issues/15#issuecomment-1847939439) +- Using the [no_mangle](https://github.com/rust-lang/rust/issues/28179) attribute in Rust +- Using compiler options which turn off some or all of the compiler's memory safety checks +- Disabling .NET's source code [Analyzers](https://learn.microsoft.com/en-gb/dotnet/fundamentals/code-analysis/overview?tabs=net-8) during build ### Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your code as well as in all your dependencies' code @@ -73,32 +73,30 @@ TO DO ### Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your code -* [Using compiler options for hardening C and C++ Code](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html) -* Using a fuzzer such as [syzkaller](https://github.com/google/syzkaller) -* Using [sanitizers](https://github.com/google/sanitizers) -* Using tools to [detect dangling pointers](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/dangling_ptr.md) -* If using Visual Studio, using the [C/C++ code analysis tool](https://learn.microsoft.com/en-us/cpp/code-quality/code-analysis-for-c-cpp-overview?view=msvc-170) -* If using Visual Studio, using the [C++ Core Guidelines checkers](https://learn.microsoft.com/en-us/cpp/code-quality/using-the-cpp-core-guidelines-checkers?view=msvc-170) -* Using [CodeQL](https://codeql.github.com/) for the [languages that CodeQL supports](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/) -* Using [BinSkim](https://github.com/microsoft/binskim) to analyze binaries -* Using [DevSkim](https://github.com/microsoft/devskim) IDE extensions/language analyzers +- [Using compiler options for hardening C and C++ Code](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html) +- Using a fuzzer such as [syzkaller](https://github.com/google/syzkaller) +- Using [sanitizers](https://github.com/google/sanitizers) +- Using tools to [detect dangling pointers](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/dangling_ptr.md) +- If using Visual Studio, using the [C/C++ code analysis tool](https://learn.microsoft.com/en-us/cpp/code-quality/code-analysis-for-c-cpp-overview?view=msvc-170) +- If using Visual Studio, using the [C++ Core Guidelines checkers](https://learn.microsoft.com/en-us/cpp/code-quality/using-the-cpp-core-guidelines-checkers?view=msvc-170) +- Using [CodeQL](https://codeql.github.com/) for the [languages that CodeQL supports](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/) +- Using [BinSkim](https://github.com/microsoft/binskim) to analyze binaries +- Using [DevSkim](https://github.com/microsoft/devskim) IDE extensions/language analyzers ### Using a non-memory safe by default language with developer best practices, but no automated tooling Examples: -* [Using attributes such as `cleanup` and classes when writing C](https://lwn.net/Articles/934679/) (and depending on developers to manually check this) -* Following the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines) when writing C++ -* Using the [C++ Compiler Hardening Guide](https://github.com/ossf/wg-best-practices-os-developers/tree/main/docs/Compiler-Hardening-Guides) when compiling C++ code -* Isolating code that processes un-trusted data from code that performs direct memory management operations or uses raw pointers (see [Language-theoretic Security](https://github.com/ossf/Memory-Safety/pull/20)) -* Using [smart pointers](https://learn.microsoft.com/en-us/cpp/cpp/smart-pointers-modern-cpp?view=msvc-170) - +- [Using attributes such as `cleanup` and classes when writing C](https://lwn.net/Articles/934679/) (and depending on developers to manually check this) +- Following the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines) when writing C++ +- Using the [C++ Compiler Hardening Guide](https://github.com/ossf/wg-best-practices-os-developers/tree/main/docs/Compiler-Hardening-Guides) when compiling C++ code +- Isolating code that processes un-trusted data from code that performs direct memory management operations or uses raw pointers (see [Language-theoretic Security](https://github.com/ossf/Memory-Safety/pull/20)) +- Using [smart pointers](https://learn.microsoft.com/en-us/cpp/cpp/smart-pointers-modern-cpp?view=msvc-170) ### Using a non-memory safe by default language without developer best practies or automated tooling Using raw C or C++ (or old versions of C and C++ language and compiler) - ## The Continuum - Getting to a Better State with re: to memory safety TO DO