blhc job complains about two missing flags not set in bookworm and older

As reported by @carnil on IRC, the blhc job is complaining about two missing flags that are set by dpkg since 1.22.0:

<carnil> [21:10] < carnil> - Check for stack clash protection (-fstack-clash-protection); requested by Emanuele Rocca (Debian Bug #1050909).
<carnil> [21:10] < carnil> - Check for branch protection (amd64: -fcf-protection, arm64: -mbranch-protection=standard); requested by Emanuele Rocca (Debian Bug #1050912).

This ends up with error for bookworm or older releases. See e.g. https://salsa.debian.org/kernel-team/linux/-/jobs/5496461:

15406:CFLAGS missing (-fstack-clash-protection -fcf-protection):   gcc -Wp,-MD,/builds/kernel-team/linux/debian/output/source_dir/debian/build/build-tools/tools/perf/plugins/.plugin_tlb.o.d -Wp,-MT,/builds/kernel-team/linux/debian/output/source_dir/debian/build/build-tools/tools/perf/plugins/plugin_tlb.o -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -I/builds/kernel-team/linux/debian/output/source_dir/tools/perf -I/builds/kernel-team/linux/debian/output/source_dir/debian/build/build-tools/tools/perf -isystem /builds/kernel-team/linux/debian/output/source_dir/debian/build/build-tools/include -fPIC -I. -I.. -I /builds/kernel-team/linux/debian/output/source_dir/tools/include '-DPLUGIN_DIR="/usr/lib/traceevent/plugins"' -D_GNU_SOURCE -D"BUILD_STR(s)=#s" -c -o /builds/kernel-team/linux/debian/output/source_dir/debian/build/build-tools/tools/perf/plugins/plugin_tlb.o plugin_tlb.c

There would be, at least, two possible solutions. From IRC:

<santiago> ... 1. create and use a blhc:${RELEASE} image/ 2. continue using blhc:latest but add  --ignore-flag -fstack-clash-protection --ignore-flag -fcf-protection for bookworm or older releases
<santiago> I don't know blhc very well, but my gut feeling is to go ahead with 2
<santiago> at a salsa-ci-team/pipeline's salsa-ci.yml level
<santiago> carnil, does that capture what you think about this?
<carnil> yes it caputred my understanding of the situation very well. I'm a bit unsere about 2 because that will mean in the pileline's salsa-ci.yml we will need to maintain the set of ignore-flags according to updates of blhc in unstable
<santiago> carnil, yes, that is true
<carnil> say 0.15-1 get uploaded adding a new set of flags, which are added in 1.22.6, then the salsa-ci-team/pipeline's salsa-ci.yml needs to be updated once more adding more ignore-flags
<santiago> in such cases, I use to contact the maintainers of the related tool
<santiago> to ask their input
<carnil> make sense
<santiago> if blhc:${RELEASE} correctly handle the flags for each release, then 1) would make more sense 
<santiago> s/handle/handles
<santiago> I will create an issue and ask blhc's maintainers opinion there

@eriberto, any opinion about how to solve this issue? Is it sensible to use blhc from each release? TIA.