Backstage audit logging with the auditor service

Backstage audit logging with the auditor service: when you need it

The Backstage auditor service records security-relevant events for the portal, and those events only help when they reach a log system your team already monitors. You need it when a security or platform team running Backstage for many engineers has to answer who did what: who registered a template, who ran a scaffolder action, who changed a catalog entity, and who signed in. A portal that keeps these answers only in its own process logs makes investigations slow and leaves retention to whoever restarts the pod. Before you plan anything, confirm in the current Backstage auditor documentation which event types your release emits, since coverage varies by plugin.

Attribution depends on sign-in. An audit record is only as useful as the user identity behind it, and the Backstage authentication documentation advises configuring sign-in resolvers so every provider resolves to the same identity and not offering guest access in production. If GitHub, Okta and a generic OIDC provider each create a different user for the same engineer, one person appears under several names in the audit trail. Check the resolver design before the auditor settings, because a clean event stream with unstable identities still cannot answer the question. Also confirm the severity levels and how they map to your log levels, since that mapping decides which events your alerts can see.

DeployOpen plans and implements this work in infrastructure you control. The engagement starts by fixing the event list you need, mapping each event type to a severity and a log level, and deciding which events reach alerting and which only feed investigations. Shipping then sends those events to the SIEM your team already runs, with tests that show each in-scope plugin emits what the design expects and that the receiving system stores the fields your analysts query. Decide early who owns the alert rules, how long events are retained, and how the audit configuration is versioned with the rest of the app, because gaps usually appear when these settings change after go-live.

Which events the auditor captures in your Backstage version

The auditor service records security-relevant activity across Backstage, but the exact event names, fields and severity mappings depend on the version you run and the plugins you install. The cards below name the four to six activity areas most teams will want to audit, and for each one what to confirm in the current auditor documentation before you write alert rules.

Sign-in and session events

Sign-in is the first place to look when you trace who reached the portal and from where. Backstage offers 19 built-in authentication providers, so the same user may appear through different providers, and the sign-in resolver decides which identity is recorded. Check whether the auditor emits events for successful and failed sign-ins, token issuance and session refresh, and whether each event carries the provider name and the resolved user entity reference. Also confirm how guest access events appear, since production guidance advises against guest access.

Catalog registration and changes

Catalog events show who added, changed or removed Users, Groups, Components and Templates. Registration is one of the easiest ways to slip a rogue entity into the portal, so you need to know whether the auditor records the acting identity or only the entity name. Confirm whether location registration, refresh and deletion each produce a distinct event, and whether entity-provider writes from automated ingestion are attributed to a service identity rather than a person. Without this, you cannot separate a human action from a sync job.

Scaffolder template runs

Each software template run executes actions on behalf of a user, and those actions can create repositories, call APIs and write secrets. Verify whether the auditor records the start and completion of each run, the template reference, the parameters submitted, and the acting user. Also check whether individual custom actions produce their own events, and whether failed steps are logged with enough detail to investigate. Parameter values can contain sensitive input, so confirm how the auditor redacts them before the events leave Backstage.

Permission decisions

Permission events show when a policy allowed or denied an action, which is central to proving access control works. Confirm whether the auditor records denials as well as grants, whether the decision includes the permission name and the requesting identity, and whether high-volume read checks are sampled or excluded. Decision logging can be noisy, so decide up front which permissions matter for your investigations and which events should be dropped at the source.

Severity and log level mapping

Audit events only help if your SIEM can rank them. Check how the auditor assigns severity levels to each event type, whether those levels map to the log levels your logging pipeline expects, and whether you can override the mapping in configuration. A mismatch here can hide failed sign-ins behind routine reads. Write down the mapping you accept, then test one event of each severity to confirm it arrives at the destination with the level you expect.

Plugin-emitted events

Not every security-relevant action runs through core Backstage code, because community and internal plugins can emit their own events or write nothing at all. Inventory the plugins you run and confirm, for each one, whether it calls the auditor and which events it produces. Gaps in this inventory are where audit trails most often break. Treat any plugin that handles credentials or external calls as a priority to verify, and record the result in your change records.

Severity levels and log level mappings to set

This table compares the decisions that shape audit output: the severity levels the auditor assigns, how Backstage log levels map onto them, and where each mapping is set. Confirm each configuration key and its default against the auditor documentation for your Backstage version before you rely on it, because the defaults are not stated here. The main takeaway is that severity and log level settings decide what reaches your SIEM, so set them deliberately and test them.

Decision	What it controls	Default to confirm	When to change it
Audit severity assigned to each event	Whether an event is recorded as informational, low, medium or high impact for triage and alerting	Confirm per event type in the auditor docs for your version	When a security-relevant action, such as a permission denial or template run, is rated too low to alert on
Backstage log level for audit output	The minimum level at which audit entries are written to the backend log stream	Confirm the logger level key and default in your app-config	When SIEM volume is too low or too high, or when debug output hides audit lines
Mapping from Backstage log levels to audit severity	How each log level is translated when an audit event is emitted	Confirm the mapping table in the auditor configuration reference	When a level such as warn is mapped to a severity your SIEM rules do not expect
Which event types are captured	Whether plugin events such as catalog changes, scaffolder runs and auth decisions are emitted at all	Confirm which plugins emit audit events in your Backstage version	When a plugin you run emits no events or emits more than your retention plan allows
Log output format and fields	Whether actor, action, resource and severity fields arrive in a shape your parser can read	Confirm the structured logging format key and field names	Before connecting a forwarder, so field mappings in the SIEM stay stable across upgrades
Severity threshold for alerting	Which audit severities trigger SIEM alerts versus storage only	Set in your SIEM, not in Backstage	After a baseline period, to cut noise without dropping high-impact events

Choosing Wazuh, Graylog or OpenSearch as the audit log destination

Wazuh is distributed under the GNU General Public License version 2, with an exception that permits linking with the OpenSSL library. It is built around endpoint monitoring and security analytics, so it fits best when a security team wants audit events correlated with host telemetry, file integrity and vulnerability data in one place. A Wazuh deployment brings four components: the Wazuh indexer, which stores alerts; the Wazuh server, which runs decoders and rules; the Wazuh dashboard; and agents on endpoints. Audit events from a Backstage host or container can arrive through a Wazuh agent or through syslog collection, depending on how you ship them.

License: GPL v2 with the OpenSSL linking exception. Confirm with your legal team how that license applies to your distribution and internal use.
Components to run: the indexer, the server (optionally as a cluster), the dashboard and the agents on the hosts that emit events.
Fit: teams that already run Wazuh for endpoint monitoring or vulnerability detection and want audit events in the same console.
Compliance views: the dashboard includes prebuilt views for frameworks such as PCI DSS, GDPR, HIPAA and NIST 800-53, which help when reviewers ask for mapped evidence.
Offline option: an offline installation guide exists for systems without internet access.

Before committing, confirm which Wazuh release line and deployment method your environment requires, and ask for a written quote from DeployOpen based on your event volume and indexer sizing.

Setting up audit event shipping step by step

This sequence takes the Backstage auditor from a disabled or default setup to a SIEM where audit events arrive with a known severity, a named actor and an entity reference, and where alerts fire on the events your security team cares about. Each step ends with a check you can run before moving on.

Confirm the auditor is enabled
The platform engineer checks which Backstage release the portal runs against the current release line on the Backstage releases page and the versioning policy, then confirms the auditor service is wired into the backend in your app's backend package. Plan the upgrade first if you are on an unsupported line, because audit event names and fields can change between releases. Confirm the exact configuration keys in the Backstage documentation for your version. The step is done when a sign-in attempt on a non-production instance writes an audit entry to the backend log.
Set the severity and log level mapping
The security lead and platform engineer decide which event types count as low, medium, high or critical severity, such as failed sign-ins, permission denials, catalog deletions and changes to templates or access policies. Then map each severity to the backend log level so that your log transport can filter on it without parsing message text. Record the mapping in a table that the SIEM team keeps with the detection rules. The step is done when a test event of each severity produces a backend log line with the expected level and severity field.
Choose the transport from backend logs
The platform engineer chooses how backend logs reach the collector, using an agent or log shipper that your team already operates, such as syslog, Beats or an OpenTelemetry Collector. Keep audit output on its own path or tag it so it can be routed separately from general application logs. Confirm the collector's input type and TLS settings with the SIEM team before opening the connection. The step is done when a single backend log line appears in the collector's raw message view within a few seconds of being written.
Create a dedicated input, stream and index
The SIEM administrator creates a separate input for audit events, a stream that matches only those messages, and an index set with its own retention and access rules. In Graylog, for example, index rotation and retention are set per index set, so audit data can be kept for a different period than application logs. Restrict who can read the index, because audit records contain user identities and entity references. The step is done when test events land only in the audit stream and no application log messages appear in it.
Parse fields for user and entity search
The SIEM administrator adds extraction rules or pipeline rules that turn the audit message into fields such as actor identity, event name, plugin, severity, entity reference and request identifier. Search on the actor field rather than free text so that investigations can follow one identity across events. Test the rules against several event types, because a rule that works for sign-ins may miss catalog or scaffolder events. The step is done when a search for a test user's identity returns every event generated by that user in the test window.
Build saved searches and alerts
The security team saves searches for repeated investigations, such as sign-in failures by identity, permission denials and deletions of catalog entities, then creates event definitions for the conditions that need a response. Route notifications to the channels your on-call process already uses, such as email, Slack or PagerDuty in Graylog, and agree who owns each alert. Keep the alert thresholds in version control with the rest of the logging configuration. The step is done when a deliberately triggered test alert reaches the owner channel with the actor and entity fields filled in.
Test with controlled sign-in and catalog changes
A tester signs in with a dedicated test identity, fails one sign-in on purpose, then creates, edits and deletes a test entity in the catalog on the non-production instance. The security lead compares the SIEM records with the expected list: identity, event name, severity and entity reference for each action. Any event that is missing, mislabeled or lacks an identity shows a gap in the mapping or parsing from earlier steps, so fix that step and repeat the test. The step is done when every controlled action appears once, with the expected fields, and the results are filed with the change record.

Which plugins emit audit events and how to test coverage

Audit coverage depends on the plugins your portal runs, not on the auditor service alone. The service only records what plugins call it to record, so the set of events you can expect is determined by your installed backend plugins. Start by listing every backend plugin in your backend package.json and entry file, including plugins that teams added for their own work. For each one, check the plugin's documentation and source code for calls to the auditor and note whether it emits events for sign-in, catalog changes, template runs or denied permissions. Confirm this against the exact plugin versions you run, because emitted events can change between releases.

Next, run a test matrix against a staging instance that uses the same configuration as production. Cover four flows: sign-in, catalog register and delete, template execution, and a permission denial that a test user triggers on purpose. For each flow, write down the event name you expect, the severity and log level your mapping assigns, and the key fields such as actor and target. Then perform the action and search your audit sink for the result. A missing event can mean the plugin never emits it, your severity mapping filters it out, or the shipping pipeline dropped it, so check each possibility before you mark the gap. Repeat the matrix after every upgrade.

Third-party and community plugins often emit no audit events at all, so treat silence as a gap, not as a pass. Record every gap in a coverage register with the plugin name and version, the missing event, any compensating evidence such as proxy logs or catalog change history, and a named owner. For each gap, decide whether to accept the risk in writing, ask the plugin maintainer for auditor support, or replace the plugin. Review the register at every upgrade and before approving any new plugin, so the record matches what actually runs in your portal.

Protecting audit data in transit and at rest

Audit events are only useful if they arrive intact, stay readable by the right people, and are kept for the right length of time. The cards below cover the controls that connect Backstage to your SIEM and protect the log store behind it, along with the identity data that each event records.

Encrypt audit events in transit

Events leave Backstage over the network to your SIEM or log collector, and they can carry user names, entity references and request details. Use TLS for every hop between the Backstage backend and the collector, and verify certificates rather than trusting any endpoint that presents one. Confirm with your SIEM vendor which protocols and certificate options its ingestion endpoint supports, and document who manages the certificate lifecycle.

Restrict read access to the log store

Only the security team should read full audit events. Engineers who use Backstage daily rarely need the complete record of who ran which action, and broad read access turns the audit store into a second copy of sensitive activity data. Limit read roles on the SIEM or log index, separate them from write roles used by the Backstage collector, and review the access list on a fixed schedule.

Set retention and deletion schedules

Audit retention should follow your written policy and any regulatory obligations you are subject to, not the default settings of the log platform. Decide how long hot, searchable events are kept, when older data is archived, and how deletion is carried out and recorded. Ask your SIEM vendor how deletion is performed on each index tier, and confirm that backups do not keep events beyond the deletion date.

Keep secrets and personal data out of events

Audit events should identify what happened without copying what was sent. Review which fields the auditor service records for each plugin, including request bodies, template parameters and configuration values that may contain tokens or personal data. Where a field can hold a credential, mask or drop it before shipping, and test with a known token to confirm it does not appear in the SIEM.

Protect audit integrity and admin duties

An audit trail that administrators can edit proves little during an investigation. Separate the people who configure Backstage and the audit pipeline from those who review and can alter stored events, and restrict deletion rights to a documented process. Verify that the collector cannot overwrite or delete historical indices, and record changes to the pipeline configuration itself as auditable events.

Verify identity recorded in events

Each audit event is only as trustworthy as the identity attached to it. Backstage advises configuring sign-in resolvers so every provider resolves to the same identity, and advises against offering guest access in production. If guest access is enabled or a resolver maps several accounts to one user, events will name the wrong person. Test each sign-in path and confirm the recorded identity before relying on the trail.

Limits to confirm before you rely on Backstage audit logs

Start by confirming that the auditor version you run covers every event your policy requires. Event coverage is tied to the Backstage release you deploy. The project ships a main release line monthly and a next release line weekly, according to its versioning policy. That cadence matters for audit trails because event names, severity values and field names can change between versions. Illustratively, a detection rule that matches a field name today may match nothing after an upgrade, and the gap would be silent. Pin the version, compare the emitted events before and after each bump, and rerun your detection tests as part of every upgrade. Do not carry coverage forward from the documentation of an older release without checking it.

Next, confirm what happens to audit events during backend restarts and outages. Ask whether events raised while the backend is restarting, or while the connection to your SIEM is down, are buffered, retried, dropped or written only to local logs. The answer decides whether a gap in your SIEM means nothing happened or means events were lost. Test this on a staging instance. Run a scripted set of actions such as catalog registrations and template runs, stop the backend and the log pipeline in turn, restart them, then compare the expected events with what arrived. Record the result in your control evidence so any gap is explained before an incident depends on that data.

Finally, plan for volume and SIEM ingest. Event volume grows with catalog size, the number of users signing in and how often templates run, so a staging test with a catalog close to production scale is the most reliable basis for sizing. Measure the events produced by a typical action, multiply by expected daily activity, and check the result against your SIEM's ingest capacity. If you use Graylog, its system architecture guidance advises sizing log storage as daily ingest times retention days times 120 percent, and the system architecture page covers message journal sizing. Ask your SIEM vendor for measured ingest figures at your expected rate, and confirm them in your own load test before relying on them.

Questions teams ask about Backstage audit logging and outside help

How much does Backstage audit logging with a SIEM cost?

Cost has three parts: the Backstage framework and its plugins, the SIEM, and the services to design and build the pipeline. Backstage is Apache-2.0 licensed, so the framework itself carries no license fee. The SIEM is where prices vary. Graylog Open is free with community support, while Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. Those are vendor list figures, not a DeployOpen price. Recurring costs include the SIEM license or hosting, storage and staff time for alert tuning. One-time costs cover design and build. Cost rises with the number of plugins emitting events, the number of event types, daily log volume and retention period. Ask any quote to itemize these components.

How long does it take to set up Backstage audit logging?

Duration depends on how many plugins emit audit events, how many event types need routing and alerting, whether a SIEM already exists, and how much of your current log pipeline can be reused. A team with a licensed SIEM, one Backstage instance and a short list of events can finish sooner than a team that must also deploy a new search backend and cluster. Build work is only part of the schedule. Validating that events arrive, that alerts fire and that the on-call owner can act on them takes time as well. For fixed-scope work, the timeline comes from the written deliverables, so it is set before work begins. Confirm the vendor requirements for your SIEM version and your own change approval windows early, because these often set the pace.

What do we need to provide before audit logging work starts?

Gather these items before scoping so the written scope reflects your environment:

The Backstage version and release line you run, plus your Node.js runtime, since Backstage supports two adjacent even-numbered Node.js releases.
The list of installed plugins and their versions, including any community plugins that emit events.
SIEM access details: the ingestion endpoint, the method you plan to use, service credentials handled through your secrets process, and the SIEM version.
A retention policy from your compliance owner that states how long audit events must be kept and where they may be stored.
A named owner for alerts who can accept, tune and act on them, with an escalation path for after-hours events.

Missing items usually show up as delays in the build phase, so it helps to confirm each one with the team that owns it.

Can our internal team set up Backstage audit logging alone?

Yes, if your team has the skills for the work. Backstage and the SIEM options discussed here are open source, so nothing blocks you from building it internally. You will need people who can configure Backstage backend plugins and their settings, people who administer the SIEM and its storage, and a security reviewer who decides which events matter and how they are classified. Teams often find the hardest part is not the setup but the ongoing work: tuning alerts so they are useful, keeping the pipeline working through Backstage upgrades, and documenting runbooks for responders. Outside help can cover design, configuration, testing and handover, or it can be kept as an ongoing retainer for upgrades and tuning. Decide which parts your team will own after the first release.

How does a fixed-scope agreement and quote work for this?

Most DeployOpen engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. DeployOpen does not publish a price list, so the quote reflects the plugins, event types, SIEM integration, retention and acceptance tests you define. A good scope names the Backstage version, the systems that will send events, the SIEM and its version, the alerts and owners, and how success will be checked. Changes to scope are handled as written changes with their own effect on cost and timing. Ongoing support, upgrades and continuous testing are available as separate retainers, so ask whether post-launch work should be quoted together with the build or separately.

Does DeployOpen issue audit reports for our logging controls?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Evidence the build can prepare includes configuration records for audit event capture, retention settings, sample events and alert runbooks. Ask your auditor which evidence they expect before scoping, because requirements differ by framework and by organization. If you plan to use a SIEM's prebuilt compliance views, confirm with the vendor which framework mappings it includes and how your team will validate them, since those mappings still need review against your own controls.

How DeployOpen scopes and delivers Backstage audit logging

DeployOpen plans and implements Backstage audit logging as a fixed-scope piece of work inside infrastructure you control. We agree which audit events matter, how they reach your log platform, and who reviews them before any configuration changes, so the result can be tested and handed over.

How we scope

Inventory which Backstage plugins are installed and which of their actions your auditors and incident responders need to see.
Agree the event fields, severity mapping and retention expectations in writing before configuration starts.
Confirm the SIEM target, its owner, and the network path from Backstage to the log pipeline.

How we build

Enable the auditor service in the Backstage backend and map its log levels to your chosen severity scheme.
Ship audit events to your SIEM with the transport and parsing rules agreed during scoping.
Test representative actions such as catalog changes and template runs, and confirm each event arrives with the expected fields.

How we hand over

Document the configuration keys, event catalog, severity mappings and SIEM parsing rules in your own repository.
Walk your security and platform teams through alert queries and a sample investigation workflow.
Record known gaps, such as plugins that do not emit audit events, so your team can decide how to close them.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer that covers audit pipeline changes after Backstage upgrades.
Re-test audit events whenever plugins are added, removed or upgraded so coverage does not silently drop.
Quotes follow from the written scope, and the scope lists what your team provides, such as SIEM access and log retention policy.

Backstage audit logging with the auditor service