Backstage Scorecards
You set up backstage scorecards by adding a grading plugin to your developer portal. The plugin reads metadata from your apps and checks them against team rules. Most engineering teams start by linking their code repos and build tools. Then they define pass or fail rules for every service in the catalog. When portal roles are too broad, anyone can edit catalog files to fake a passing grade. Overly wide permissions also let plugins read sensitive data from every connected system. How backstage
Backstage Security Plugins: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up backstage scorecards by adding a grading plugin to your developer portal. The plugin reads metadata from your apps and checks them against team rules. Most engineering teams start by linking their code repos and build tools. Then they define pass or fail rules for every service in the catalog. When portal roles are too broad, anyone can edit catalog files to fake a passing grade. Overly wide permissions also let plugins read sensitive data from every connected system.
How backstage scorecards work in your portal
A developer portal keeps track of all your software components in one central catalog. Each service has a descriptor file that lives right next to its source code. This file lists the owner, the system type, and links to outside tools. When you add backstage scorecards, the portal starts grading these services against your standards.
First, the scorecard plugin pulls fresh facts from your connected developer tools. It checks your source control system to see if branch rules are active. It asks your alert tool if the team has an on-call schedule set up. It also reads bug trackers to count open security tickets for that app.
Next, the grading engine runs your custom rules against those collected facts. You might group these rules into bronze, silver, and gold levels. A service needs basic ownership tags and a readme file to reach bronze. Silver might require automated tests and active error tracking. Gold often demands strict security checks and fast recovery plans.
Finally, the portal displays the grades on the service page for everyone to see. Team leads can view a summary board to spot weak services across the company. Developers see exact steps to fix failing checks and raise their score.
What portal checks solve and the runtime gap they leave
Scorecards are great for tracking service health and pushing standards across many teams. They replace messy spreadsheets with live checks that update on their own. New engineers can look at a service score and know if it is ready. Leaders can track company goals like upgrading old code libraries or adding alert rules.
Still, a scorecard only checks how a system looks on paper. It verifies static files and tool settings at a single point in time. It cannot see or control what engineers actually do during a live session.
Backstage Security Plugins: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
For example, a database service might earn a gold score in the portal. The scorecard sees that backups run and that role settings look right. Yet when an engineer logs in to fix a bug, the scorecard steps aside. Native setup rules only decide who can log in to the database or server. They do not check individual queries, commands, or requests while they run in flight.
An engineer with a valid role can still run a bad delete command. A script can still pull thousands of customer emails or card numbers without warning. To stay safe, teams must pair portal checks with controls over live commands. Masking tools that rewrite matched fields in results help protect raw data during live work.
Steps to keep your service grades accurate
Start small when you roll out grades to your engineering teams. Pick three or four basic rules that every team can pass in one week. If you add fifty hard rules on day one, developers will ignore the board.
Lock down who can edit the catalog files and scorecard rules in source control. Require a review from a platform team member before changing any grading logic. Audit the keys that your portal uses to read facts from outside tools. Give those keys read-only roles so the portal cannot change production settings by mistake.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Do backstage scorecards come built into the base portal?
No, the core open-source portal does not include a grading engine out of the box. You must install a community plugin, buy a commercial add-on, or build your own plugin.
How often do service grades update in the catalog?
Update speed depends on how your specific plugin fetches data from outside tools. Most setups pull fresh facts on a set schedule or when code changes happen.
Can a failing scorecard block a production deploy?
The portal itself only displays grades and does not run your build pipelines. Still, your deploy scripts can call the portal API to check a score before releasing code.