Security advisories and dependency currency

Why this page

Your LuxID integration is only as secure as the day you last patched it. Two currents move under a working integration: LuxID evolves (security notices, key rotation, deprecations), and your dependencies age (the OIDC and JWT libraries that validate LuxID tokens accumulate CVEs like any other software). This page describes how to stay current on both, and who to contact when something security-relevant happens.

Staying informed about LuxID security notices

LuxID communicates operational and security-relevant information by email to the Partner contact list registered with LuxID. If your contact list is stale, you miss advisories - there is no way to catch up retroactively.

Concretely:

1. Register a security contact. The recommended Partner contact list includes a technical, a business, and a security contact - see Account contact list. Make the security contact a role mailbox (for example security@yourcompany.lu), not a person who might leave.
2. Ask to be included in security notices. Request via Partner support that your security contact receives security advisories, deprecation announcements, and change-window notifications, not only incident notifications.
3. Audit the contact list quarterly. A bounce on an advisory email is silent from your side.

LuxID also publishes its security reporting details in machine-readable form per RFC 9116 (opens in a new tab) at /.well-known/security.txt - see Reporting a security vulnerability.

Keeping OIDC and JWT libraries current

The libraries that parse and validate LuxID tokens sit directly on your trust boundary. Historic vulnerability classes in JWT libraries - alg: none acceptance, RS256-to-HS256 key-confusion, missing audience checks - are exactly the bugs that turn "we validate the ID token" into "anyone can forge a session". RFC 8725 (JSON Web Token Best Current Practices, IETF, February 2020) (opens in a new tab) catalogues these pitfalls; a current, well-maintained library is your first line of defence against all of them.

Practical rules:

• Use a maintained, mainstream library - the ones listed in Code samples and reference repos and Platform and framework guides are chosen partly for maintenance track record.
• Pin versions, but update on a cadence. Pinning without a review cadence is how integrations end up three major versions and four CVEs behind. A monthly dependency review is a reasonable floor for an authentication path.
• Automate the update proposal. Tools such as Dependabot (opens in a new tab) or Renovate (opens in a new tab) open update pull requests automatically; your job reduces to reviewing and merging.
• Treat security patches to the auth path as expedited. A CVE in your JWT validation library is not "next sprint" work.

Checking CVEs for the libraries you use

Do not wait for a breach write-up to learn your token library had a known flaw. Wire at least one advisory source into your pipeline:

Source	What it gives you
OSV.dev (opens in a new tab)	Cross-ecosystem vulnerability database with per-package API; osv-scanner runs in CI
GitHub Security Advisories (opens in a new tab)	Advisory database backing Dependabot alerts; covers npm, Maven, PyPI, NuGet, Composer, Go and more
NVD (opens in a new tab)	The NIST CVE registry - authoritative but slower and less package-aware; useful for formal reporting
Ecosystem-native audit	npm audit, pip-audit, dotnet list package --vulnerable, mvn org.owasp:dependency-check-maven:check - cheap to add to CI

Minimum viable setup: enable Dependabot (or Renovate) on the repository that contains your LuxID integration, and fail CI on known-vulnerable versions of your OIDC/JWT dependencies via an ecosystem-native audit step.

Key-rotation readiness

LuxID signs tokens with RS256 and publishes its public keys at the JWKS endpoint. LuxID will rotate signing keys - and a rotation must be a non-event for you. It is one only if your integration refreshes keys correctly:

• Resolve keys by kid, never hardcode a key. A pinned public key turns every rotation into your outage.
• Cache the JWKS, and refresh on unknown kid. When a token arrives with a kid not in your cache, re-fetch the JWKS once before rejecting the token. This single behaviour makes rotation seamless.
• Do not fetch the JWKS on every request. That is a performance bug and can trigger rate limits.

The full pattern, including cache TTLs and library configuration, is in Key management.

Readiness test: in UAT, ask yourself whether a new kid appearing in tokens tomorrow would require a code change or deployment on your side. If the answer is yes, fix the JWKS handling before it happens in production.

Incident contact path

Route security events to the right mailbox on the first attempt:

Situation	Contact
You discovered a vulnerability in LuxID itself	CSIRT POST CyberForce, csirt@post.lu - coordinated disclosure, PGP available. See Reporting a security vulnerability
Your Client Secret leaked or your integration is compromised	Partner support (servicedesk@post.lu) to request immediate credential rotation; call +352 2424 3030 for P1. See Client credentials
A personal-data breach on your side involves LuxID-sourced claims	Your own DPO first; LuxID data-protection questions go to privacy@post.lu

Partner self-check

• Security contact (role mailbox) registered on the LuxID Partner contact list
• Contact list audited within the last quarter
• Automated dependency updates enabled for the integration repository
• CI fails on known-vulnerable OIDC/JWT library versions
• JWKS resolved by kid, cached, refreshed on unknown kid - no hardcoded keys
• Credential-leak runbook names servicedesk@post.lu and the P1 phone number

Related pages

• Key management - JWKS caching and rotation handling in detail
• Protect your application - the baseline security checklist
• Client credentials - secret storage and rotation
• Contact and support channels - the canonical mailbox routing