An extra enhancement would be to see the complete redirect path, but just showing the full resolved path of the sectxt would already indeed be very useful.

I think I have a patch. Note that is will only update the 'retrieved from', not the 'requested from', since the last one will likely otherwise show /security.txt because the legacy path is tried as a fallback:

Some samples of 'Technical details' (of rijksoverheid.nl and example.org):

Another thing is this would break all old reports, since they don't have the url in the database. I fixed this by filling in the url with the host variable for old reports. So the url will only show in new reports (once this is merged and deployed).

Maybe the dot should be removed behind the url for easier copying? It's still there because I just changed the {hostname} to {url}, without changing the message.

I think I have a patch. Note that is will only update the 'retrieved from', not the 'requested from', since the last one will likely otherwise show /security.txt because the legacy path is tried as a fallback:

True, though we could preserve the original path. I think this approach is reasonable too.

Another thing is this would break all old reports, since they don't have the url in the database. I fixed this by filling in the url with the host variable for old reports. So the url will only show in new reports (once this is merged and deployed).

Yes, this backfill is a good approach.

Maybe the dot should be removed behind the url for easier copying? It's still there because I just changed the {hostname} to {url}, without changing the message.

We should remove the dot, yes