[08/10] security-manual: use the bitbake code-block language

diff --git a/documentation/security-manual/read-only-rootfs.rst b/documentation/security-manual/read-only-rootfs.rst
index 251178ed5458..55eb853dc239 100644
--- a/documentation/security-manual/read-only-rootfs.rst
+++ b/documentation/security-manual/read-only-rootfs.rst
@@ -23,13 +23,17 @@  Creating the Root Filesystem
 To create the read-only root filesystem, simply add the
 "read-only-rootfs" feature to your image, normally in one of two ways.
 The first way is to add the "read-only-rootfs" image feature in the
-image's recipe file via the :term:`IMAGE_FEATURES` variable::
+image's recipe file via the :term:`IMAGE_FEATURES` variable:
+
+.. code-block:: bitbake
 
    IMAGE_FEATURES += "read-only-rootfs"
 
 As an alternative, you can add the same feature
 from within your :term:`Build Directory`'s ``local.conf`` file with the
-associated :term:`EXTRA_IMAGE_FEATURES` variable, as in::
+associated :term:`EXTRA_IMAGE_FEATURES` variable, as in:
+
+.. code-block:: bitbake
 
    EXTRA_IMAGE_FEATURES = "read-only-rootfs"
 
diff --git a/documentation/security-manual/securing-images.rst b/documentation/security-manual/securing-images.rst
index 13ab63ddd8be..3c01c1f643bd 100644
--- a/documentation/security-manual/securing-images.rst
+++ b/documentation/security-manual/securing-images.rst
@@ -82,7 +82,9 @@  your build output more secure. The security flags are in the
 
 Use the following line in your ``local.conf`` file or in your custom
 distribution configuration file to enable the security compiler and
-linker flags for your build::
+linker flags for your build:
+
+.. code-block:: bitbake
 
    require conf/distro/include/security_flags.inc
 
@@ -96,7 +98,9 @@  system to make your images more secure:
    and allow the use of empty passwords or root logins. This is typically
    done by adding the values "allow-empty-password", "allow-root-login", and
    "empty-root-password" to your build's image features, commonly with the
-   addition of the line::
+   addition of the line:
+
+   .. code-block:: bitbake
 
       EXTRA_IMAGE_FEATURES = "allow-empty-password empty-root-password allow-root-login"
 
diff --git a/documentation/security-manual/sstate-signing.rst b/documentation/security-manual/sstate-signing.rst
index 74a5d6bf07da..565f51e843ab 100644
--- a/documentation/security-manual/sstate-signing.rst
+++ b/documentation/security-manual/sstate-signing.rst
@@ -86,7 +86,9 @@  they are generated. The generation of new artifacts is done once a task has
 finished being executed.
 
 For the following sections let's assume that the build system has the shared
-state directory location (:term:`SSTATE_DIR`) defined as follows::
+state directory location (:term:`SSTATE_DIR`) defined as follows:
+
+.. code-block:: bitbake
 
    SSTATE_DIR = "${TOPDIR}/sstate-cache"
 
@@ -120,7 +122,9 @@  Enabling Shared State Signing
 -----------------------------
 
 Create a new :term:`configuration file` on your host **in a safe location** and
-add the two following statements::
+add the two following statements:
+
+.. code-block:: bitbake
 
    SSTATE_VERIFY_SIG = "1"
    SSTATE_SIG_KEY = "4049A47E3AAA99D0250966DC5B97632FA7F4E942"
@@ -196,7 +200,9 @@  you can verify them with the public key counterpart of the private key.
    shared between multiple hosts.
 
 From a :term:`configuration file` such as the :ref:`site configuration file
-<structure-build-conf-site.conf>`, include the following statements::
+<structure-build-conf-site.conf>`, include the following statements:
+
+.. code-block:: bitbake
 
    SSTATE_VERIFY_SIG = "1"
    SSTATE_VALID_SIGS = "5B97632FA7F4E942"
@@ -255,7 +261,9 @@  Let's verify that signature verification works:
 .. note::
 
    To make sure shared state verification is working, you can set a "fake"
-   public key identifier in :term:`SSTATE_VALID_SIGS`::
+   public key identifier in :term:`SSTATE_VALID_SIGS`:
+
+   .. code-block:: bitbake
 
       SSTATE_VALID_SIGS = "CAFECAFECAFECAFE"
 
diff --git a/documentation/security-manual/vulnerabilities.rst b/documentation/security-manual/vulnerabilities.rst
index 38fbd2c7e358..e3fc6fe768b8 100644
--- a/documentation/security-manual/vulnerabilities.rst
+++ b/documentation/security-manual/vulnerabilities.rst
@@ -35,7 +35,9 @@  Directory`:
 
    $ bitbake-config-build enable-fragment core/yocto/sbom-cve-check
 
-Or add the following statement to a :term:`configuration file`::
+Or add the following statement to a :term:`configuration file`:
+
+.. code-block:: bitbake
 
    OE_FRAGMENTS += "core/yocto/sbom-cve-check"
 
@@ -44,7 +46,9 @@  recommended settings to use it.
 
 The CVE database contains some old incomplete entries which have been deemed not
 to impact :term:`OpenEmbedded-Core (OE-Core)`. These CVE entries can be excluded
-from the check by adding the following statement::
+from the check by adding the following statement:
+
+.. code-block:: bitbake
 
    include conf/distro/include/cve-extra-exclusions.inc
 
@@ -165,7 +169,9 @@  in the recipe name to CVE product mapping. These mapping issues can be fixed by
 the :term:`CVE_PRODUCT` variable inside the recipe. This defines the name of the software component in the
 upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
-The variable supports using vendor and product names like this::
+The variable supports using vendor and product names like this:
+
+.. code-block:: bitbake
 
    CVE_PRODUCT = "flex_project:flex westes:flex"
 
@@ -200,7 +206,9 @@  version does or likely might introduce incompatibilities, extracting and
 backporting patches is preferred.
 
 Here is an example of fixing CVE security issues with patch files,
-an example from the :oe_layerindex:`ffmpeg recipe for dunfell </layerindex/recipe/122174>`::
+an example from the :oe_layerindex:`ffmpeg recipe for dunfell </layerindex/recipe/122174>`:
+
+.. code-block:: bitbake
 
    SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
               file://mips64_cpu_detection.patch \
@@ -283,7 +291,9 @@  status to ``Patched`` in the generated reports.
 If analysis shows that the CVE issue does not impact the recipe due to configuration, platform,
 version or other reasons, the CVE can be marked as ``Ignored`` by using
 the :term:`CVE_STATUS` variable flag with appropriate reason which is mapped to ``Ignored``.
-The entry should have the format like::
+The entry should have the format like:
+
+.. code-block:: bitbake
 
    CVE_STATUS[CVE-2016-10642] = "cpe-incorrect: This is specific to the npm package that installs cmake, so isn't relevant to OpenEmbedded"
 
@@ -364,7 +374,9 @@  Example:
    $ cd openembedded-core/meta/recipes-kernel/linux/
    $ ./generate-cve-exclusions.py ~/cvelistV5 6.12.27 > ~/meta-custom/recipes-kernel/linux/cve-exclusion_6.12.inc
 
-Don't forget to update your kernel recipe with::
+Don't forget to update your kernel recipe with:
+
+.. code-block:: bitbake
 
    include cve-exclusion_6.12.inc
 
@@ -396,7 +408,9 @@  build a binary. Therefore, it needs to be configured in the kernel to extract
 the kernel compiled files.
 
 If you are using the ``linux-yocto`` recipe, enable it by adding the following
-in a :term:`configuration file` or in a ``.bbappend``::
+in a :term:`configuration file` or in a ``.bbappend``:
+
+.. code-block:: bitbake
 
    KERNEL_EXTRA_FEATURES:append = " features/debug/debug-kernel.scc"
 
@@ -413,7 +427,9 @@  The sources for the kernel are stored under
 ``tmp/pkgdata/<MACHINE>/debugsources/linux-yocto-debugsources.json.zstd``. In
 order to include the information into the :term:`SPDX` file to filter out
 source files that are not used to compile the kernel, add the following in a
-:term:`configuration file`::
+:term:`configuration file`:
+
+.. code-block:: bitbake
 
    SPDX_INCLUDE_COMPILED_SOURCES:pn-linux-yocto = "1"