You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: SECURITY.md
+65-11Lines changed: 65 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
<!-- BEGIN MICROSOFT SECURITY.MD V0.0.9 BLOCK -->
2
2
3
-
##Security
3
+
# Security
4
4
5
5
Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations.
6
6
@@ -16,13 +16,13 @@ You should receive a response within 24 hours. If for some reason you do not, pl
16
16
17
17
Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
18
18
19
-
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
20
-
* Full paths of source file(s) related to the manifestation of the issue
21
-
* The location of the affected source code (tag/branch/commit or direct URL)
22
-
* Any special configuration required to reproduce the issue
23
-
* Step-by-step instructions to reproduce the issue
24
-
* Proof-of-concept or exploit code (if possible)
25
-
* Impact of the issue, including how an attacker might exploit the issue
19
+
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
20
+
* Full paths of source file(s) related to the manifestation of the issue
21
+
* The location of the affected source code (tag/branch/commit or direct URL)
22
+
* Any special configuration required to reproduce the issue
23
+
* Step-by-step instructions to reproduce the issue
24
+
* Proof-of-concept or exploit code (if possible)
25
+
* Impact of the issue, including how an attacker might exploit the issue
26
26
27
27
This information will help us triage your report more quickly.
28
28
@@ -38,6 +38,60 @@ Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https:
38
38
39
39
<!-- END MICROSOFT SECURITY.MD BLOCK -->
40
40
41
+
## Repository Security Stance
42
+
43
+
This repository is a **learning playground** for Azure API Management. Its security posture reflects a deliberate balance: enforce real-world best practices wherever they do not impede the learning workflow, and clearly document every intentional relaxation so users know what to tighten for production.
44
+
45
+
### What We Enforce
46
+
47
+
#### Supply chain and CI
48
+
49
+
* GitHub Actions use least-privilege `permissions:` blocks, SHA-pinned third-party actions, `persist-credentials: false` on `actions/checkout`, and no `pull_request_target`.
50
+
* Dependabot, Dependency Review, and OpenSSF Scorecard are configured.
51
+
*`pip-audit` runs in CI as a non-blocking supply-chain vulnerability check.
* No real secrets are committed. `.gitignore` and `.dockerignore` coverage is comprehensive.
57
+
* Managed identity and APIM named values are used for backend credentials; no hardcoded keys in policies.
58
+
* APIM subscription keys in Bicep outputs are annotated with `#disable-next-line outputs-should-not-contain-secrets` and an inline comment explaining intent. The Bicep linter rule is set to `warning` globally so that any *unintentional* secret output is caught.
59
+
* Python helpers redact sensitive headers (`api-key`, `Authorization`, `Ocp-Apim-Subscription-Key`, `x-api-key`) before logging. The `print_secret()` utility masks secret values in notebook output.
* JWT validation via `validate-jwt` and `validate-azure-ad-token` is demonstrated in the `authX`, `authX-pro`, and `oauth-3rd-party` samples.
65
+
* APIM policy error handlers return generic messages to callers; detailed diagnostics are emitted to Application Insights via `<trace>`.
66
+
67
+
#### Development tooling
68
+
69
+
* Local preview servers (`serve_website.py`, `serve_presentation.py`) bind to `127.0.0.1`, not `0.0.0.0`.
70
+
* Jupyter notebook cell outputs are cleared before commit to prevent leaking resource names or subscription IDs.
71
+
72
+
### Intentional Compromises for Learning
73
+
74
+
The following defaults prioritise a frictionless learning experience. **Every one of them is parameterised** and can be flipped to the secure setting for production use.
|`apimPublicAccess = true`| Lets learners call APIM from their machine without VPN or private networking setup. | Disable public access; use Private Endpoints or VNet integration. |
79
+
|`useStrictNsg = false`| Avoids NSG rules that block notebook or CLI connectivity during experiments. | Enable strict NSGs scoped to required ports and sources. |
80
+
| WAF in `Detection` mode | Prevents the WAF from blocking exploratory requests while learners iterate. | Switch to `Prevention` mode once rules are tuned. |
81
+
|`enablePurgeProtection = false` on Key Vault | Allows quick tear-down of lab environments without waiting for the purge-protection retention period. | Enable purge protection. |
82
+
|`revealBackendApiInfo = true` (X-Backend-URL header) | Helps learners observe routing decisions and backend selection in responses. | Remove or disable the header; do not expose internal URLs. |
83
+
| Subscription-key-only auth on admin APIs | Keeps sample setup simple. Each admin API includes a `SECURITY` comment pointing to `authX`/`authX-pro`. | Layer JWT validation (`validate-azure-ad-token` or `validate-jwt`). |
84
+
| APIM subscription keys returned in Bicep outputs | Notebooks need keys to generate test traffic. Outputs use `#disable-next-line` with an intent comment. | Fetch keys via RBAC-controlled mechanisms; remove them from outputs. |
85
+
86
+
### What Is Not a Vulnerability
87
+
88
+
These items were reviewed and intentionally not flagged:
89
+
90
+
***`allowInsecureTls=True` for Application Gateway infras** -- correctly scoped to AppGW infrastructure types (self-signed certificate by design); the flag is `False` for all other infrastructures.
91
+
***`shell=True` in Azure CLI wrappers** -- commands are constructed from controlled internal strings, never from user-supplied input.
92
+
***Application Insights instrumentation keys in Bicep outputs** -- Microsoft treats these as non-secret connection identifiers.
93
+
***`ast.literal_eval` fallback in JSON parsing** -- this is the safe `ast` module function, not `eval`.
94
+
41
95
## Security Scanning Scope
42
96
43
97
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.
@@ -48,8 +102,8 @@ This repository does not implement dedicated fuzz testing, and the Scorecard Fuz
48
102
49
103
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:
50
104
51
-
- Bicep, policy XML, and notebooks are declarative assets consumed by Azure-side tooling, not by code in this repository.
52
-
- The Python helpers read output from the operator's own `az` CLI session and their own policy files.
53
-
- 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).
105
+
* Bicep, policy XML, and notebooks are declarative assets consumed by Azure-side tooling, not by code in this repository.
106
+
* The Python helpers read output from the operator's own `az` CLI session and their own policy files.
107
+
* 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).
54
108
55
109
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.
0 commit comments