Listen to this Post
A Quiet Platform Change That Could Affect Dashboards, Billing, and Automation
Modern software development depends heavily on automation. Teams no longer run every security or quality check manually, because platforms such as GitHub allow organizations to integrate analysis directly into the development lifecycle. Every pull request, commit, and workflow can trigger automated checks designed to identify vulnerabilities, maintain coding standards, and prevent poor-quality code from reaching production.
That automation, however, creates another challenge: organizations build dashboards, billing reports, scripts, monitoring systems, and internal automation around the metadata produced by those workflows.
GitHub’s latest change to GitHub Code Quality may appear simple at first glance. Code Quality runs are now separated from GitHub code scanning runs at the workflow infrastructure level. But for organizations that have built reporting or automation around the old identifiers, this change could quietly break filters, distort usage reports, or cause internal monitoring systems to miss Code Quality activity.
The change does not require repositories to reconfigure GitHub Code Quality itself. Existing repositories can continue scanning normally. The important work is happening around the workflows, particularly for teams that rely on the previous workflow path or actor identity to track analysis activity.
The Core Change: GitHub Code Quality Now Has Its Own Workflow Path
GitHub has made a dedicated workflow path for Code Quality generally available. Previously, Code Quality activity shared infrastructure identifiers associated with GitHub code scanning.
Under the new separation, GitHub Code Quality analysis runs through:
dynamic/github-code-quality/codeql
Code scanning continues to use its separate workflow identity.
This means that Code Quality activity is no longer grouped under the same workflow path that organizations may have historically used to identify GitHub code scanning operations.
The change may sound like a backend implementation detail. In reality, identifiers become important the moment engineers use them in automation.
A path inside a usage report is not just a label. It can become part of financial reporting, security dashboards, engineering metrics, API integrations, scripts, and internal governance systems.
Once an organization starts filtering on that identifier, changing it becomes an operational event.
A New Actor Identity for GitHub Code Quality
The separation also changes the actor associated with GitHub Code Quality runs.
Code Quality now appears with:
github-code-quality
Previously, systems may have identified these runs through:
github-advanced-security
This distinction matters because many organizations use workflow actors as a simple method for categorizing activity.
A script may ask a basic question:
if [[ "$ACTOR" == "github-advanced-security" ]]; then echo "Security analysis detected" fi
That logic may no longer recognize GitHub Code Quality runs if the system expects only the old actor.
The workflow itself may still run successfully.
The analysis may still complete.
The repository may still receive results.
But the
That is exactly the type of infrastructure change that can remain invisible until someone notices that a dashboard suddenly shows fewer scans than expected.
Why GitHub Is Separating Code Quality From Code Scanning
Security analysis and code quality analysis often overlap, but they are not identical disciplines.
Code scanning is primarily associated with identifying security vulnerabilities, dangerous coding patterns, and weaknesses that may expose an application or infrastructure to attack.
Code quality focuses more broadly on the maintainability, structure, reliability, and overall health of software.
Both may rely on sophisticated static analysis technology.
Both may run inside automated workflows.
Both may analyze the same repository.
Yet organizations may want to measure them separately.
A security team may care about vulnerability analysis.
An engineering organization may care about technical debt and code quality trends.
A finance or platform engineering team may care about how automation usage translates into consumption and cost.
Separating workflow identities makes those categories easier to distinguish.
Existing Repositories Do Not Need to Reconfigure GitHub Code Quality
One of the most important details is that GitHub Code Quality itself does not require users to rebuild or reconfigure their existing setup.
Repositories with Code Quality already enabled can continue operating.
Scanning behavior remains available.
Developers do not need to manually replace their existing analysis configuration simply because GitHub changed the underlying workflow classification.
This reduces the operational burden for ordinary users.
However, organizations that built external systems around the previous identifiers should review those systems carefully.
The platform configuration may continue working.
The surrounding ecosystem may not.
That difference is critical.
Actions Usage Reports Could Need Updating
Organizations that track GitHub Actions usage should review their reporting logic.
Any report filtering exclusively for:
dynamic/github-code-scanning/codeql
may fail to account for the newly separated Code Quality workflow path:
dynamic/github-code-quality/codeql
This could produce incomplete usage data.
Imagine a monthly engineering report that tracks automated analysis consumption.
Before the separation, a filter may have captured both security scanning and Code Quality activity through one path.
After the change, the same report could suddenly show lower usage.
An analyst might conclude that engineering teams reduced their scanning activity.
In reality, the activity may simply have moved into a different category.
This is a classic observability problem.
The underlying system is functioning.
The measurement layer is outdated.
Billing Automation Could Be Affected by the New Classification
Billing systems are particularly sensitive to metadata changes.
Some organizations export GitHub Actions usage into internal accounting or cost-allocation platforms.
They may categorize workflow activity based on names, paths, actors, repositories, or workflow metadata.
If a billing report recognizes only the older CodeQL workflow path, Code Quality usage may no longer appear in the expected category.
The result could be inaccurate internal chargeback reports.
A platform engineering team may think one department is consuming less automation capacity than before.
Another department may appear to have unexplained changes in usage.
The actual issue may be as simple as a filter that has not been updated.
A small metadata change can therefore create a surprisingly large reporting problem.
Scripts and Dashboards Need a Careful Review
Organizations should search their automation for references to both the previous workflow path and actor identity.
For example:
grep -R dynamic/github-code-scanning/codeql .
Teams should also search for the previous actor:
grep -R github-advanced-security .
These searches may reveal scripts that classify Code Quality activity using the old identifiers.
After identifying those references, teams can update their logic to recognize the new Code Quality path and actor.
For example:
if [[ "$WORKFLOW_PATH" == "dynamic/github-code-scanning/codeql" ]] || \n[[ "$WORKFLOW_PATH" == "dynamic/github-code-quality/codeql" ]]; then echo "Code analysis workflow detected" fi
The goal is not necessarily to merge both categories forever.
In many cases, organizations may want to report them separately.
The important step is making the distinction intentional rather than accidentally losing visibility.
The Change Is Also Important for Security Operations
Security teams frequently aggregate data from multiple developer tools.
A security dashboard may count:
Code scanning runs
Vulnerability findings
Repository coverage
Security automation events
Advanced security activity
Code analysis execution
If those systems use actor-based classification, the new github-code-quality actor may need to be explicitly added.
Otherwise, a dashboard designed around github-advanced-security could become incomplete.
This does not necessarily mean security coverage has been reduced.
It may simply mean the monitoring logic has not caught up with the platform.
That distinction is extremely important during audits.
A missing metric can look like missing security activity.
GitHub Code Quality and Code Scanning Are Becoming More Clearly Distinguishable
The dedicated workflow path represents a broader architectural improvement.
As developer platforms become more complex, shared identifiers can create ambiguity.
A single analysis engine may support multiple products or features, but organizations increasingly need to understand exactly what type of activity occurred.
Separating Code Quality from code scanning creates cleaner telemetry.
It allows organizations to answer more precise questions.
How much security scanning are we running?
How much code quality analysis are we running?
Which teams rely most heavily on each capability?
How does automation usage change over time?
Which costs belong to which category?
These questions become easier to answer when the underlying workflow metadata is distinct.
Enterprise Organizations Have the Most Reason to Review Their Automation
Smaller teams may not notice the change at all.
If a development team simply enables GitHub Code Quality and views results through the GitHub interface, the transition may be almost invisible.
Enterprise environments are different.
Large organizations often maintain:
Internal observability platforms
Custom billing pipelines
Security information dashboards
Compliance reports
Workflow analytics
API integrations
Data warehouses
Automated governance systems
Each of these systems may depend on stable metadata.
A simple actor change can therefore travel through multiple layers of infrastructure.
The GitHub workflow succeeds.
The event reaches an API.
A collector retrieves the data.
A transformation script processes it.
A dashboard categorizes the result.
One outdated condition inside that chain can create misleading information.
The Availability of GitHub Code Quality Continues Across Supported Plans
GitHub Code Quality is available through GitHub Enterprise Cloud and GitHub Team, including GitHub Enterprise Cloud environments with data residency.
This makes the workflow separation relevant to a wide range of organizations.
Cloud-native development teams may use it to monitor software quality.
Enterprise security and platform teams may integrate the resulting workflow data into broader engineering systems.
Organizations using data residency environments may also need to ensure that their internal reporting and automation recognize the updated workflow identifiers.
The technical feature may remain unchanged from the user’s perspective.
The metadata surrounding the feature is what has evolved.
What Undercode Say:
The Real Impact Is Not on Scanning, It Is on Visibility
The most interesting part of this announcement is that GitHub is not asking developers to rebuild their Code Quality configuration.
The scanners keep working.
The repositories continue running analysis.
The potential disruption appears at the operational layer.
This is where many organizations are vulnerable.
Infrastructure teams often assume that workflow metadata is stable.
They build dashboards around actor names.
They write billing rules around workflow paths.
They create alerts based on event classifications.
Then a platform provider improves its internal architecture.
The product becomes more organized.
But the
Metadata Should Be Treated Like an API Contract
Organizations should stop treating workflow names and actor identities as harmless strings.
Once automation depends on them, they effectively become part of an internal API contract.
A simple comparison such as this:
[[ $ACTOR == github-advanced-security ]]
can become a hidden dependency.
The script may have been written years ago.
The engineer who created it may no longer work on the project.
Nobody remembers why that condition exists.
Then the provider changes the metadata.
The script does not crash.
It simply stops detecting activity.
Silent failures are often more dangerous than visible failures.
Separate Identities Improve Long-Term Observability
The new separation should ultimately improve reporting.
Security scanning and code quality analysis can now be identified independently.
That creates cleaner telemetry.
Organizations can measure security automation separately from engineering quality automation.
This distinction becomes increasingly valuable as software development becomes more automated.
Artificial intelligence is generating more code.
Repositories are becoming larger.
Automated analysis is running more frequently.
Engineering teams need more precise metrics, not less.
Dashboards Should Avoid Fragile Exact-Match Logic
A mature observability system should not depend on a single hard-coded value when a category may evolve.
Instead of writing:
if [[ "$ACTOR" == "github-advanced-security" ]]; then classify="analysis" fi
organizations should consider controlled mapping logic:
case $ACTOR in
github-advanced-security)
classify="security-analysis" ;; github-code-quality) classify="code-quality-analysis" ;; ) classify="other" ;; esac
This approach makes future changes easier to manage.
It also creates explicit categories.
Billing Systems Need Defensive Design
Cost reporting is especially vulnerable to platform changes.
A better approach is to maintain version-controlled mapping files.
For example:
workflow_categories:
dynamic/github-code-scanning/codeql:
category: security
dynamic/github-code-quality/codeql:
category: quality
This makes classification transparent.
It also allows teams to review changes through normal pull requests.
Metadata rules should be infrastructure as code.
The Change Signals Product Maturity
GitHub is gradually separating concepts that previously shared infrastructure identities.
That is usually a sign that a product ecosystem is becoming more specialized.
Code scanning has its own role.
Code quality has its own role.
The underlying technology may overlap, but the business and engineering use cases are becoming more distinct.
This could eventually lead to more specialized reporting, analytics, and governance features.
Organizations Should Test Before Their Next Reporting Cycle
The best time to update filters is before the next monthly billing or engineering report.
A simple validation can compare historical workflow activity with the newly classified paths.
For example:
grep -E "github-code-scanning|github-code-quality" workflow-data.json
Teams should compare totals.
Unexpected drops should be investigated.
The question should not immediately be, “Did our scanning decrease?”
The first question should be, “Did our classification logic change?”
Automation Dependencies Need Documentation
This announcement also exposes a common DevSecOps weakness.
Many organizations document their CI/CD pipelines.
Few document every metadata dependency used by external reporting systems.
A workflow path may be referenced in:
grep -R "github-code" /opt/automation/
The result may reveal dependencies across scripts, containers, dashboards, and infrastructure repositories.
Without documentation, platform changes become detective work.
GitHub Users Should Build Flexible Integrations
The safest long-term strategy is not to assume identifiers will never change.
Instead, organizations should build integrations that are observable, version-controlled, and regularly tested.
A daily validation job can detect unexpected workflow categories:
jq -r ‘.workflow_path’ workflow-data.json | sort | uniq
New values can then trigger review.
That turns unexpected metadata changes into visible operational events.
Code Quality Will Become More Important as AI Generates More Software
The timing of this separation is also interesting.
AI-assisted development is increasing the volume of generated code.
More code does not automatically mean better software.
Organizations will need automated systems capable of checking security, maintainability, consistency, and reliability.
GitHub Code Quality may therefore become increasingly important.
Separating its workflow identity now creates a clearer foundation for future analytics.
The Biggest Risk Is Organizational Blindness
The real danger is not that Code Quality stops working.
The danger is that an organization believes it has complete visibility when it does not.
A dashboard can look perfectly healthy while silently ignoring a new category.
A billing report can appear accurate while excluding part of the activity.
An audit can report declining analysis coverage when the actual coverage has simply moved.
That is why metadata changes deserve the same attention as API changes.
Final Undercode Assessment
This is a positive architectural change.
The dedicated workflow path provides cleaner separation between security scanning and code quality analysis.
However, the migration burden falls on organizations with custom automation.
GitHub users should audit filters now rather than waiting for missing metrics to appear later.
The lesson is broader than GitHub.
In modern DevSecOps, identifiers are infrastructure.
Paths are infrastructure.
Actors are infrastructure.
And when infrastructure metadata changes, automation must evolve with it.
Deep Analysis
Step One: Find References to the Old Workflow Path
Administrators can search automation repositories for the older identifier:
grep -RIn dynamic/github-code-scanning/codeql .
This command recursively searches files and displays matching line numbers.
Any result should be reviewed to determine whether the logic also needs to recognize GitHub Code Quality.
Step Two: Search for the Previous Actor
Teams should also locate references to the previous actor:
grep -RIn github-advanced-security .
Some references may still be correct for security scanning.
The important task is identifying cases where that actor was also being used to classify Code Quality activity.
Step Three: Detect the New Identity
Search for the newly introduced workflow values:
grep -RIn github-code-quality .
This can help identify whether parts of the organization have already updated their automation.
Step Four: Compare Workflow Categories
If workflow records are stored in JSON format, administrators can inspect unique workflow paths:
jq -r ‘.workflow_path’ runs.json | sort | uniq -c
This produces a count of each workflow path.
A sudden appearance of dynamic/github-code-quality/codeql should be expected after the separation.
Step Five: Update Classification Rules
A defensive Bash classification example could look like this:
case $WORKFLOW_PATH in
dynamic/github-code-scanning/codeql)
echo "GitHub Code Scanning" ;; dynamic/github-code-quality/codeql) echo "GitHub Code Quality" ;; ) echo "Unknown workflow category" ;; esac
The advantage of this approach is visibility.
Unknown values do not silently disappear.
They become visible.
Step Six: Monitor for Future Changes
A scheduled job can collect unique workflow paths and compare them with an approved list:
jq -r '.workflow_path' runs.json | sort -u > current_paths.txt diff approved_paths.txt current_paths.txt
If the platform introduces another workflow identity, the difference becomes visible immediately.
This is a simple but powerful observability technique.
The Workflow Separation
✅ The supplied GitHub announcement states that GitHub Code Quality now uses the dedicated dynamic/github-code-quality/codeql workflow path instead of sharing the previous CodeQL path used for code scanning.
The Actor Change
✅ The announcement states that GitHub Code Quality runs now appear with the github-code-quality actor rather than being identified through the github-advanced-security actor.
Repository Reconfiguration
✅ Existing repositories do not need to reconfigure GitHub Code Quality itself, but organizations using custom reports, scripts, dashboards, or filters based on the older identifiers may need to update their automation.
Prediction
The Future of GitHub Code Quality Observability
(+1) GitHub’s separation of Code Quality and code scanning identities will likely improve long-term reporting, allowing organizations to measure software quality analysis and security analysis as distinct engineering activities.
More enterprises are likely to build dedicated dashboards for code quality automation instead of grouping all CodeQL-related activity into one category.
AI-generated code will increase the demand for automated quality analysis, making dedicated Code Quality telemetry more valuable.
Organizations that fail to update legacy filters may temporarily experience inaccurate billing reports, incomplete dashboards, or misleading workflow metrics.
Future platform changes could expose additional hidden dependencies where organizations have hard-coded GitHub metadata into automation without version control or monitoring.
A Broader Prediction for DevSecOps
(+1) The next stage of DevSecOps will increasingly focus not only on whether automated security and quality tools run, but also on whether organizations can accurately observe, classify, measure, and explain every automated action across the software development lifecycle.
▶️ Related Video (74% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: github.blog
Extra Source Hub (Possible Sources for article):
https://www.reddit.com/r/AskReddit
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
