Address fuzz testing (#170)

Author: simonkurtz-MSFT

.github/scorecard.yml

@@ -0,0 +1,29 @@
+# OpenSSF Scorecard maintainer annotations.
+#
+# These DO NOT change numeric check scores. Scorecard's Fuzzing check is
+# binary (0 or 10) and annotations are applied after scoring. What they do
+# is surface a maintainer-provided reason alongside the 0/10 so that anyone
+# reading the report (CLI --show-annotations, REST API, scorecard.dev viewer)
+# sees context instead of an unexplained failure.
+#
+# Schema and reason vocabulary:
+#   https://github.com/ossf/scorecard/blob/main/config/README.md
+#
+# Valid reasons: test-data, remediated, not-applicable, not-supported, not-detected
+
+annotations:
+  - checks:
+      - fuzzing
+    reasons:
+      # This repository is a learning playground: Bicep templates, Jupyter
+      # notebooks, APIM policy XML, and thin Python wrappers around the Azure
+      # CLI. The Python helpers do not parse untrusted attacker-controlled
+      # input — the only parsing surface (json_utils.py) delegates to the
+      # standard library's json and ast modules, which are already fuzzed
+      # upstream in CPython via OSS-Fuzz. All other inputs originate from the
+      # operator's own Azure tenant or their own policy files.
+      #
+      # Scorecard also has no Python-native fuzzer detection (Go / Haskell /
+      # JS / Erlang only), so even adding hypothesis or atheris tests would
+      # not move this score. See SECURITY.md for the full rationale.
+      - reason: not-applicable

SECURITY.md

@@ -37,3 +37,19 @@ We prefer all communications to be in English.
 Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/security.md/cvd).
 
 <!-- END MICROSOFT SECURITY.MD BLOCK -->
+
+## Security Scanning Scope
+
+This repository is scanned by [OpenSSF Scorecard](https://github.com/ossf/scorecard) via a scheduled GitHub Action. Some checks will report a low score by design; the rationale is recorded as maintainer annotations in [`.github/scorecard.yml`](.github/scorecard.yml) and summarised below.
+
+### Fuzzing
+
+This repository does not implement dedicated fuzz testing, and the Scorecard Fuzzing check is expected to report `0/10`. This is a deliberate scoping decision rather than an oversight.
+
+Fuzz testing is most valuable where code parses untrusted, attacker-controlled input — file formats, network protocols, deserialisers — particularly in memory-unsafe languages. This repository is a learning playground composed of Bicep templates, Jupyter notebooks, APIM policy XML, and thin Python wrappers around the Azure CLI. None of these components parse untrusted input locally:
+
+- Bicep, policy XML, and notebooks are declarative assets consumed by Azure-side tooling, not by code in this repository.
+- The Python helpers read output from the operator's own `az` CLI session and their own policy files.
+- The only parsing surface (`shared/python/json_utils.py`) delegates to the Python standard library `json` and `ast` modules, which are [already fuzzed upstream in CPython via OSS-Fuzz](https://github.com/google/oss-fuzz/tree/master/projects/cpython3).
+
+Scorecard additionally has no Python-native fuzzer detection — only OSS-Fuzz enrolment, ClusterFuzzLite, or language-native fuzzers for Go, Haskell, JavaScript/TypeScript, and Erlang are recognised. Adding `hypothesis` or `atheris` property-based tests would therefore not change the score, and would only exercise standard-library code paths already covered upstream.