From eee2e163d2fa3cae57b7b39bcc992b5770058f21 Mon Sep 17 00:00:00 2001 From: Patrik Oldsberg Date: Tue, 17 Dec 2024 14:47:46 +0100 Subject: [PATCH] Update microsite/blog/2024-12-17-backstage-security-audit-2024.mdx MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Fredrik Adelöw Signed-off-by: Patrik Oldsberg --- microsite/blog/2024-12-17-backstage-security-audit-2024.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/microsite/blog/2024-12-17-backstage-security-audit-2024.mdx b/microsite/blog/2024-12-17-backstage-security-audit-2024.mdx index 726e2db4a7..f9a1afef9e 100644 --- a/microsite/blog/2024-12-17-backstage-security-audit-2024.mdx +++ b/microsite/blog/2024-12-17-backstage-security-audit-2024.mdx @@ -19,7 +19,7 @@ The security audit and improvements concluded on October 16. The audit findings We are happy to see that there are no repeated vulnerabilities, perhaps in part due to our new [secure coding practices](https://github.com/backstage/backstage/blob/master/SECURITY.md#coding-practices) following the previous audit, as well as the introduction of the [Backstage Threat Model](https://backstage.io/docs/overview/threat-model). While there was a path traversal vulnerability that was discovered in the TechDocs backend, this was more specific and related to remote paths, rather than the local filesystem. We chose to handle this as an isolated fix as there are no other occurrences of this pattern that we are aware of. -The [previous security audit](https://backstage.io/blog/2022/08/23/backstage-security-audit/) highlighted the need for Backstage to have its own built-in protection, to be secure by default. This, as well as the need for more robust service-to-service auth, was addressed earlier this year through the new auth system, in [1.24](https://backstage.io/docs/releases/v1.24.0#breaking-auth-improvements) and following releases. The new auth system was in scope for this new security audit, and no findings were made in the areas. +The [previous security audit](https://backstage.io/blog/2022/08/23/backstage-security-audit/) highlighted the need for Backstage to have its own built-in protection, to be secure by default. This, as well as the need for more robust service-to-service auth, was addressed earlier this year through the new auth system, in [1.24](https://backstage.io/docs/releases/v1.24.0#breaking-auth-improvements) and following releases. The new auth system was in scope for this new security audit, and no findings were made in that area. One area with findings in both audits is the way that the auth plugin backend handles sign-in of users. This is a complex area that can often be a source of friction for the adoption experience of Backstage. As part of this audit we have made several updates especially to the documentation for sign-in resolvers, but this remains an area where it is hard to find a solution that is both simple and secure. Of course we err on the side of caution and have updated our documentation to be more strict. We will continue to explore options for improvements to the sign-in system to keep it both simple and secure out of the box, but in the meantime be sure to read the documentation section [sign-in identity and resolver](https://backstage.io/docs/auth/identity-resolver) as you are setting up Backstage.