B&E Code signing only verifies the author. In other words it only check who you are, but not what have you done

I think answer is D & E.

why the other options aren't as ideal: A. Ensure every code check-in is peer reviewed by a security SME: Manual reviews can become a bottleneck in agile environments and are less scalable than automated tools. C. Ensure you have stubs to unit test all interfaces between components: Good practice, but primarily focuses on functional rather than security testing. D. Enable code signing and a trusted binary repository...: Integrity checks are essential but don't directly prevent the introduction of the security errors themselves.

Cyber Sec professional here. Question asks to reduce chance of security errors accidentally introduced. This means to integrate Static Application Security Tests (SAST) and Dynamic Application Security Tests (DAST) as part of CI/CD pipeline. Hence B and E are the right match. D is to ensure only trusted code is deployed to production, not reduce 'security error accidentally introduced'.

I guess A and C are both time consuming and labor intensive. Also, aren't C stubs supposed to be used for unit tests? What remains is BDE. B is source code inspection. Doing D ensures that the repository is not contaminated. E's vulnerability scan detects whether there are any CVEs. I think all of them are correct. If you had to choose two, what would it be? Isn't it really slow if you do B and E?

https://cloud.google.com/blog/products/devops-sre/devsecops-and-cicd-using-google-cloud-built-in-services

The thing that makes me think D makes sense is that it ensures that only images that have passed though the configured CI/CD pipeline (with vulnerability checks) will be able to be deployed. This is better explained here: https://cloud.google.com/blog/products/containers-kubernetes/guard-against-security-vulnerabilities-with-container-registry-vulnerability-scanning

https://cloud.google.com/blog/products/containers-kubernetes/guard-against-security-vulnerabilities-with-container-registry-vulnerability-scanning

Code signing only verifies the author not content

DE https://cloud.google.com/blog/products/containers-kubernetes/guard-against-security-vulnerabilities-with-container-registry-vulnerability-scanning

trusted binary repository option seems a static thing. For a release if we haven not used any new packages, trusted binary repository would not add any extra value. So B&E which will are needed for every checking/release.

B and E is the answer for me also.

here you can find why: https://cloud.google.com/blog/products/devops-sre/devsecops-and-cicd-using-google-cloud-built-in-services

B) Using source code security analyzers as part of the CI/CD pipeline can help identify security vulnerabilities and issues early in the development process. This can help reduce the risk of security errors being accidentally introduced and ensure that security is integrated into the development process from the beginning. E) Running a vulnerability security scanner as part of the CI/CD pipeline can help identify vulnerabilities and issues in the code and infrastructure before they are deployed to production. This can help reduce the risk of security errors being accidentally introduced and ensure that security is integrated into the development process from the beginning.

B. Use source code security analyzers as part of the CI/CD pipeline E. Run a vulnerability security scanner as part of your continuous-integration /continuous-delivery (CI/CD) pipeline These actions ensure that security is integrated into the development and deployment processes and helps catch security issues early in the software development lifecycle.

ChatGPT says B & E :-)

B? There is no category of product called "source code security analyzer"