📦

Audit History

azure-prepare - 5 audits

Version comparison

Capability and finding changes across audited versions, newest first.

Version	Date	Result	Review items	Change vs previous
v5 Latest	Jul 23, 2026, 06:56 PM	16 confirmed	8	No capability change
v4	Jul 8, 2026, 09:23 AM	14 confirmed	2	No capability change
v3	Jul 6, 2026, 05:56 PM	6 confirmed	6	No capability change
v2	Jun 30, 2026, 07:32 AM	2 confirmed	3	No capability change
v1	Feb 21, 2026, 08:39 AM	No confirmed findings	0	Baseline

Audit version 5 Latest

Jul 23, 2026, 06:56 PM

Most static matches are documentation false positives, including Markdown links, SDK environment lookups, and Azure resource identifiers. Confirmed risks include a pipe-to-shell installer, broad network rules, embedded storage keys, and an unsafe session-secret fallback. Semantic review found prompt injection, unverified remote templates, and approval bypasses; 279 capped static matches still require manual review. Static review was capped at 400/679 representative findings; omitted static matches are unconfirmed, so automatic publishing stays disabled until manual review.

165

Files scanned

16,653

Lines analyzed

Review items

False positives ignored

Confirmed security concerns (16)

Critical

references/sdk/azd-deployment.md:8

Pipe to shell pattern

curl -fsSL https://aka.ms/install-azd.sh | bash

This command downloads a mutable remote installer and pipes it directly into Bash without pinning, checksum verification, or inspection. A compromised redirect or installer would gain arbitrary shell execution.

Critical

SKILL.md:12-14 references/services/functions/templates/README.md:61-75

Prompt Injection Attempt Detected

SKILL.md claims "AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE" and orders exact compliance. The Function template guide states "Skip content verification" because files are "pre-validated," suppressing independent review of remote content.

Both files assert trusted authority and instruct the agent to reduce scrutiny. The remote content is then written and deployed.

Critical

references/services/functions/templates/README.md:61-81 references/services/functions/templates/README.md:136-169

Unvalidated Remote Templates Can Be Written and Deployed

Function guidance writes every remote path and content exactly as supplied, without validating path containment. It then skips review and deploys the result, enabling malicious templates to overwrite files or execute cloud changes.

The instructions explicitly use remote path and content values unchanged, skip content verification, and run azd up without prompts.

High

references/services/app-service/deployment-slots.md:69

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

The template obtains a storage account key with listKeys() and places the resulting connection string in application settings. Anyone able to read those settings receives a reusable storage credential.

High

references/services/app-service/deployment-slots.md:71

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

The AzureWebJobsStorage setting embeds a storage account key returned by listKeys(). This creates a long-lived shared credential in the Function App configuration.

High

references/services/app-service/deployment-slots.md:91

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

The staging-slot template stores a listKeys() storage credential in WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Slot configuration readers can recover and reuse that account key.

High

references/services/app-service/deployment-slots.md:93

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

The staging slot receives AzureWebJobsStorage as a shared-key connection string. This exposes a reusable storage credential through application settings.

High

references/services/functions/bicep.md:176

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

The Bicep example calls listKeys() and embeds the storage account key in AzureWebJobsStorage. Managed identity settings would avoid placing this reusable credential in app configuration.

High

references/services/functions/bicep.md:212

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

The Function App content connection string contains a storage account key obtained through listKeys(). The generated application settings therefore hold a reusable shared credential.

High

references/services/functions/bicep.md:214

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

The AzureWebJobsStorage value embeds a listKeys() account key in the production Function App settings. This increases exposure compared with identity-based storage configuration.

High

references/services/functions/bicep.md:234

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

The staging slot stores a storage account key inside WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Access to slot settings would disclose a credential usable outside the application.

High

references/services/functions/bicep.md:236

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

The staging AzureWebJobsStorage setting contains a shared storage account key from listKeys(). This creates avoidable secret material in deployment configuration.

High

references/runtimes/nodejs.md:117

Environment file access

secret: process.env.SESSION_SECRET || 'dev-secret-change-in-prod',

The production configuration falls back to the known value dev-secret-change-in-prod when SESSION_SECRET is absent. A production misconfiguration would permit attackers to forge signed sessions.

High

SKILL.md:39 references/services/functions/templates/recipes/composition.md:38 references/services/functions/templates/recipes/composition.md:79 references/services/functions/templates/recipes/composition.md:123-129 references/services/functions/templates/recipes/composition.md:202-215 references/recipes/azd/terraform.md:227-245

Bundled References Bypass Approval and Validation

The core skill limits itself to preparation and requires approval plus validation. Bundled references instead deploy without prompts, which can provision billable resources before the required handoff.

The core rule forbids deployment, while the loaded Function workflow explicitly deploys and requires noninteractive commands.

High

references/services/container-apps/day2-operations.md:108-118

Shell Secret Substitution Can Expose Plaintext

The guidance claims command substitution avoids process-list exposure. Shell expansion places the secret in the Azure CLI argument vector, where local process inspection or logging may capture it.

The documented command expands secret.txt into a command-line argument, despite the adjacent claim that this avoids process-list disclosure.

High

references/services/event-grid/bicep.md:6-12 references/services/event-grid/bicep.md:45-52 references/services/event-grid/bicep.md:64-71

Event Grid Template Uses Public Shared-Key Access

The Event Grid pattern enables public network access and authenticates publishers with a topic key from environment variables. This conflicts with the skill's private-network and managed-identity guidance.

The template explicitly enables public access and constructs both clients with a reusable EVENTGRID_TOPIC_KEY.

Capability review items (8)

These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.

High

references/services/durable-task-scheduler/bicep.md:21

Hardcoded IP address

ipAllowlist: ['0.0.0.0/0'] // Required: empty list denies all traffic

The generated ipAllowlist uses 0.0.0.0/0, explicitly allowing traffic from every IPv4 address. RBAC remains required, but the network boundary is removed for the scheduler endpoint.

High

references/services/container-apps/day2-operations.md:22

Unix shell invocation

az containerapp exec -n $APP -g $RG --command /bin/sh

This command opens /bin/sh inside a running Azure Container App. It enables arbitrary remote command execution and access to runtime data without an explicit confirmation requirement at this location.

High

references/services/container-apps/day2-operations.md:28

Unix shell invocation

--command /bin/sh

The command argument launches a remote shell in the live container. That shell can inspect secrets or modify runtime state, so it should require explicit operator confirmation.

High

references/runtimes/nodejs.md:117

Environment variable access (dot notation)

secret: process.env.SESSION_SECRET || 'dev-secret-change-in-prod',

This environment lookup has a fixed, publicly documented fallback secret. If SESSION_SECRET is missing in production, session signatures become predictable.

High

references/runtimes/nodejs.md:117

Environment variable object

secret: process.env.SESSION_SECRET || 'dev-secret-change-in-prod',

The sample reads SESSION_SECRET but silently substitutes a known default. That default can enable session forgery when the deployment omits the environment variable.

Medium

references/services/sql-database/bicep.md:49

Hardcoded IP address

startIpAddress: '0.0.0.0'

In an Azure SQL firewall rule, 0.0.0.0 is the special Allow Azure services setting. It permits network access from resources across Azure instead of limiting access to this application.

Medium

references/services/sql-database/bicep.md:50

Hardcoded IP address

endIpAddress: '0.0.0.0'

The matching end address completes Azure SQL's broad Allow Azure services firewall rule. Authentication is still required, but the database network boundary is much wider than necessary.

Medium

references/services/app-service/templates/web-app.md:108

Hardcoded URL

CSRF_TRUSTED_ORIGINS = ['https://*.azurewebsites.net']

The Django template trusts every azurewebsites.net subdomain as a CSRF origin. Because unrelated tenants can control those subdomains, the trust pattern is broader than the deployed application's origin.

Risk Factors

⚙️ External commands (50)

📁 Filesystem access (50)

🔑 Env variables (50)

🌐 Network access (50)

⚡ Contains scripts (8)

references/services/durable-task-scheduler/dotnet.md:63 references/services/durable-task-scheduler/dotnet.md:72 references/services/durable-task-scheduler/dotnet.md:80 references/services/durable-task-scheduler/dotnet.md:90 references/services/durable-task-scheduler/dotnet.md:106 references/services/durable-task-scheduler/dotnet.md:140 references/services/functions/templates/recipes/common/health-check.md:54 references/services/functions/templates/recipes/common/nodejs-entry-point.md:81

Detected Patterns

Pipe to shell pattern

Audited by: codex

Audit version 4

Jul 8, 2026, 09:23 AM

The skill is primarily Markdown guidance for preparing azd-based Azure deployments, and most static findings are benign references, placeholders, or security-aware examples. Confirmed risks remain for a remote pipe-to-shell installer, storage account key-derived app settings, and a hardcoded session-secret fallback in Node.js guidance. Additional context risks include mandatory hidden plan-file writes, potential exposure of azd environment values, and optional broad SQL database grants.

165

Files scanned

16,653

Lines analyzed

Review items

False positives ignored

Confirmed security concerns (14)

Critical

references/sdk/azd-deployment.md:8

Pipe to shell pattern

curl -fsSL https://aka.ms/install-azd.sh | bash

The install guidance pipes a remote script from aka.ms directly into bash. Even though it installs azd, this pattern executes network content without local integrity verification.

High

references/runtimes/nodejs.md:117

Environment file access

secret: process.env.SESSION_SECRET || 'dev-secret-change-in-prod',

The example falls back to a literal session secret when SESSION_SECRET is missing. If copied into production, cookie signing would depend on a predictable default value.

High

references/services/app-service/deployment-slots.md:69

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

The Bicep app setting builds a storage connection string using an account key from listKeys. This is standard for some Functions scenarios, but it places a sensitive key-derived value into generated app configuration.

High

references/services/app-service/deployment-slots.md:71

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

High

references/services/app-service/deployment-slots.md:91

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

High

references/services/app-service/deployment-slots.md:93

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

High

references/services/functions/bicep.md:176

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

High

references/services/functions/bicep.md:212

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

High

references/services/functions/bicep.md:214

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

High

references/services/functions/bicep.md:234

Certificate/key files

{ name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', value: 'DefaultEndpointsProtocol=https;AccountNa

High

references/services/functions/bicep.md:236

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

Medium

SKILL.md:31 SKILL.md:50-56

Mandatory Hidden Plan File Write Before Approval

The skill requires creating .azure/deployment-plan.md in the workspace as the first action, before the plan is complete and before normal execution approval.

The instructions explicitly require an immediate workspace file write and repeat that the hidden .azure path must exist. The behavior is intentional and not just a static path match.

Medium

references/aspire.md:252-263 references/services/sql-database/scripts/grant-sql-access.sh:26-36 references/services/sql-database/scripts/grant-sql-access.ps1:25-29

azd Environment Values May Be Displayed or Loaded

Several references use azd env get-values to verify or load environment values. These values can include deployment secrets, so careless logging can expose sensitive configuration.

The command is shown directly and the scripts load all azd environment values into process variables. The risk is exposure through logs or shell history rather than deliberate exfiltration.

Medium

references/services/sql-database/scripts/grant-sql-access.sh:70-80 references/services/sql-database/scripts/grant-sql-access.ps1:62-73

Optional Broad SQL Database Role Grant

The SQL access helper can grant db_ddladmin to an application identity when SQL_GRANT_DDLADMIN is true. This may exceed least privilege after migrations finish.

Both scripts conditionally add the application identity to db_ddladmin. The comments explain the migration use case, but the privilege remains broad if left enabled.

Capability review items (2)

These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.

High

references/runtimes/nodejs.md:117

Environment variable access (dot notation)

secret: process.env.SESSION_SECRET || 'dev-secret-change-in-prod',

The example falls back to a literal session secret when SESSION_SECRET is missing. If copied into production, cookie signing would depend on a predictable default value.

High

references/runtimes/nodejs.md:117

Environment variable object

secret: process.env.SESSION_SECRET || 'dev-secret-change-in-prod',

The example falls back to a literal session secret when SESSION_SECRET is missing. If copied into production, cookie signing would depend on a predictable default value.

Risk Factors

⚙️ External commands (161)

📁 Filesystem access (58)

🔑 Env variables (127)

🌐 Network access (66)

⚡ Contains scripts (8)

Detected Patterns

Pipe to shell pattern

Audited by: codex

Audit version 3

Jul 6, 2026, 05:56 PM

Most static findings are benign Markdown examples, relative documentation links, Azure project paths, or environment variable placeholders. I confirmed the pipe-to-shell installer, permissive SQL firewall examples, and a storage key written into app settings. I also found prompt-injection language, user-confirmation bypass guidance, secret printing examples, and shared-key IaC patterns.

183

Files scanned

18,434

Lines analyzed

Review items

False positives ignored

Confirmed security concerns (6)

Critical

references/sdk/azd-deployment.md:8

Pipe to shell pattern

curl -fsSL https://aka.ms/install-azd.sh | bash

The reference tells users to run a remote installer through curl piped directly to bash. Even for an official Azure URL, this pattern executes network content without inspection or integrity verification.

Critical

SKILL.md:11-13

Prompt Injection Attempt Detected

SKILL.md labels itself authoritative and tells the agent to IGNORE prior training because it supersedes all other sources. This attempts to override higher-priority instructions during skill execution.

The file uses explicit authority, ignore, and supersede language in the primary skill instructions. This directly matches prompt injection indicators from the audit instructions.

High

references/services/functions/bicep.md:149

Certificate/key files

{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccount.n

The Bicep example writes a storage account key into the AzureWebJobsStorage app setting using listKeys(). That places a long-lived shared key in application configuration.

High

references/services/functions/templates/SPEC-composable-templates.md:24-26 references/services/functions/templates/SPEC-composable-templates.md:541-542

User Confirmation Bypass Guidance

The template specification rewards zero user intervention and says the agent never asks for more information. That conflicts with approval and ask_user safety gates for Azure context and destructive actions.

The guidance appears twice in the same specification and explicitly discourages user elicitation. The risk is contextual because it is in a template spec, not the top-level rules.

High

references/services/key-vault/sdk.md:14-15 references/services/key-vault/sdk.md:29-30 references/services/key-vault/sdk.md:41-42

Secret Values Printed in Key Vault Examples

The Key Vault SDK examples retrieve a database secret and immediately print the secret value. Copying this pattern can expose production secrets in logs or chat output.

Node.js, Python, and .NET examples print the retrieved secret value directly. This is clear secret disclosure behavior even though it appears in example code.

High

references/services/functions/bicep.md:149 references/services/container-apps/bicep.md:72-73 references/services/logic-apps/bicep.md:82-83

Shared Access Keys Embedded in IaC Configuration

Several Bicep examples use listKeys to place storage, Log Analytics, or Service Bus shared keys directly into app configuration. Long-lived shared keys should be replaced with managed identity or Key Vault references where supported.

The examples directly call listKeys and assign the returned shared keys into resource configuration. This is a concrete secret-handling weakness in generated IaC guidance.

Capability review items (6)

These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.

High

references/services/functions/templates/recipes/sql/bicep/sql.bicep:103 references/services/sql-database/bicep.md:45

Hardcoded IP address · 2 occurrences

startIpAddress: '0.0.0.0'

The SQL firewall example uses 0.0.0.0 for the allow rule, which enables broad Azure service access to the database server. This is a permissive network default that should require explicit justification.

High

references/services/functions/templates/recipes/sql/bicep/sql.bicep:104 references/services/sql-database/bicep.md:46

Hardcoded IP address · 2 occurrences

endIpAddress: '0.0.0.0'

High

references/services/functions/templates/recipes/sql/terraform/sql.tf:83

Hardcoded IP address

start_ip_address = "0.0.0.0"

High

references/services/functions/templates/recipes/sql/terraform/sql.tf:84

Hardcoded IP address

end_ip_address = "0.0.0.0"

Static false positives ignored (26)

These static matches were dismissed by semantic review or matched schema-only tokens, so they are shown for transparency but do not drive the quality score.

Critical

references/architecture.md:69

Azure credentials directory

Record selections in `.azure/plan.md` with rationale for each choice.