Conversation
A customer (MySQL Flexible Server) saw the "Azure SQL Database — TLS 1.2 enforced" evidence check show "0 passed" while the Storage check showed a count. The ticket suspected a missing ctx.pass() summary, but the SQL TLS check already emits ctx.pass() identically to Storage. The real cause is a coverage gap: the SQL check targets Microsoft.Sql/servers (Azure SQL Database), and the customer runs Azure Database for MySQL Flexible Server (Microsoft.DBforMySQL/flexibleServers) — a different resource type — so the check finds zero servers and no-ops (0 results), while Storage found 2. Add a MySQL Flexible Server TLS check that targets the correct resource type and reads TLS enforcement from server parameters (require_secure_transport + tls_version), since MySQL Flexible Server has no top-level minimalTlsVersion like Azure SQL. Compliant = require_secure_transport ON and tls_version floor permits only TLS 1.2+ (handles the comma-separated TLSv1.2,TLSv1.3 set). Maps to the same TLS/HTTPS evidence task so the customer's databases are verified. Follows existing conventions: no-op on zero resources, explicit "could not verify" on a config read failure (no false pass), pass/fail with evidence + remediation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…check The same coverage-gap class as the MySQL Flexible Server fix: the Azure manifest scans Microsoft.Sql/servers and Microsoft.DBforMySQL/flexibleServers but NOT Microsoft.DBforPostgreSQL/flexibleServers, so a customer running only PostgreSQL Flexible Server gets 0 servers found → "0 passed" for the TLS task. Add azure-postgresql-flexible-tls, mapped to the same TLS/HTTPS task. Like MySQL, TLS lives in server parameters, but PostgreSQL differs: ssl_min_protocol_ version is a SINGLE value (not MySQL's comma-separated tls_version set) and may be unset by default — PostgreSQL Flexible Server only allows TLS 1.2/1.3 and denies 1.0/1.1 regardless, so require_secure_transport=ON is the real determinant and an unset SSL floor is treated as compliant (avoids false-failing default-secure servers). api-version 2024-08-01 (its own RP/ version train, not MySQL's 2023-12-30). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…as "could not verify"
cubic flagged that a read failure of ssl_min_protocol_version was silently
treated as compliant: readConfigValue returned null for BOTH "value unset" and
"fetch failed", and `?? ''` coalesced both into a pass — masking permission /
transient errors.
Replace it with readConfig() returning a discriminated { ok, value }: a thrown
fetch -> { ok:false } -> explicit "Could not verify" finding; a successful read
with an absent/unset value -> "" -> a legitimate TLS 1.2 floor (PostgreSQL
Flexible Server denies <1.2 regardless) -> compliant. The two outcomes are no
longer conflated. Added a regression test for the ssl-read-failure path.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…s-check feat(integration-platform): add Azure MySQL + PostgreSQL Flexible Server TLS checks
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
…atch metric-filter auto-fix Customer (aymenrc) auto-fix kept failing with an AI-generated "could not determine which CloudTrail log group to attach the metric filter to" across all CloudWatch CIS metric-filter fixes. Earlier PRs (#3050/#3052/#3054) fixed the PutMetricFilter param shape and prompt wording, but never the actual blocker: nothing ever told the fix WHICH log group to use. The check already calls DescribeTrails and reads CloudWatchLogsLogGroupArn, but only to compute a boolean — it discarded the log group. The finding evidence was just { keywords, filterFound:false } and the remediation said the generic "the CloudTrail log group", so the AI had to guess the name and bailed (canAutoFix: false), surfacing that message verbatim. The prompt's claim that "the system will resolve the real one from readSteps" was unbacked — there is no deterministic resolver, only a flaky second LLM pass. Fix (adapter, the right layer — zero new AWS calls/IAM): - Capture the integrated trail's CloudWatchLogsLogGroupArn and derive the bare log-group name (logGroupNameFromArn). - Put the concrete name into the metric-filter-missing finding's remediation text + evidence (cloudWatchLogGroupName); for the existing-filter update case, use the filter's own logGroupName (from DescribeMetricFilters). - Point the AI prompt at the evidence field instead of a placeholder. The "no CloudTrail->CloudWatch integration" prerequisite is unchanged (separate early-return finding). No customer reconnect — a re-scan regenerates findings with the log group, then auto-fix works. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…p (remove AI dependency) Belt-and-suspenders for the CloudWatch metric-filter fix. The adapter now puts the real CloudTrail log group in the finding evidence, but the fix plan is still AI-generated. Add a deterministic override (applyResolvedMetricFilterLogGroup): after the plan is finalized, force logGroupName on every PutMetricFilterCommand step from the finding evidence (cloudWatchLogGroupName for a missing filter, logGroupName for an existing-filter update), in both the preview and execute paths. The executed value is now guaranteed correct regardless of what the model produced. Scoped to PutMetricFilter steps; no-op for other commands or when no log group was resolved. Extracted to a prisma-free util so it's unit-testable. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…, Sonnet 4.6) The auto-fix flow leans heavily on the LLM to emit exact AWS SDK commands as structured output; newer models follow instructions + schemas more reliably, which should raise auto-fix success rates across the board. Bump the two remediation models that were behind: - MODEL: claude-opus-4-6 -> claude-opus-4-8 (plan generation/refinement/repair) - FALLBACK_MODEL: claude-sonnet-4-5 -> claude-sonnet-4-6 (manual-steps fallback) Descriptions intentionally stay on claude-haiku-4-5 (already current, and the right tier for simple cached explanatory text — Sonnet would add cost + latency for no clear gain). Typecheck confirms the SDK accepts the new model ids; this is a config/behavior change, so validate auto-fix output on a few real findings before relying on it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…r-loggroup fix(cloud-security): resolve the real CloudTrail log group for CloudWatch metric-filter auto-fix
chore(cloud-security): upgrade remediation models to latest (Opus 4.8, Sonnet 4.6)
Contributor
|
🎉 This PR is included in version 3.74.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.
Summary by cubic
Adds TLS 1.2 enforcement checks for Azure MySQL and PostgreSQL Flexible Server, and fixes CloudWatch metric-filter auto-fix by pinning the real CloudTrail log group. Also upgrades remediation models for more reliable auto-fix plans.
New Features
mysqlFlexibleTlsCheckforMicrosoft.DBforMySQL/flexibleServers; compliant whenrequire_secure_transportis ON andtls_versionpermits only TLSv1.2+ (e.g.TLSv1.2,TLSv1.3); mapped to the TLS/HTTPS task and exported inchecks/index.tsandazure/index.ts.postgresqlFlexibleTlsCheckforMicrosoft.DBforPostgreSQL/flexibleServers; compliant whenrequire_secure_transportis ON andssl_min_protocol_versionis TLSv1.2/1.3 or unset; mapped to the TLS/HTTPS task and exported inchecks/index.tsandazure/index.ts.Bug Fixes
cloudWatchLogGroupNamefor missing-filter, or the filter’slogGroupName), and force it onto everyPutMetricFilterCommandin preview and execute; updated prompt guidance accordingly.ssl_min_protocol_versionas compliant and surface config read failures as “Could not verify”.claude-opus-4-8(primary) andclaude-sonnet-4-6(fallback) to improve plan reliability.Written for commit 8ec2cff. Summary will update on new commits.