Survey Topic Suggestion from Twitter

[infosecdad]

https://twitter.com/SecurityKsl/status/1366295111936655362

Suggested: IMHO Insecure build envorinment should be added to the list

[Keeseeel]

I'm happy that someone already added my comment from twitter here :)

Just to clarify what I meant by that. In 2020 and 2021 we see "DevOps" everywhere, people rely more and more on automation and tools trying to build fully automated pipelines where humans are not touching production servers at all.

Fully automated pipelines bring a lot of good, but if we forget some basics around pipeline protection we may end up with introducing even more risks to our product.

Few examples of vulnerabilities in this category would include:

1. Developers pushing straight to Master branch w/o any review --> risk of introducing vulnerability, backdoor or simply causing app unavailability.
2. Lack of segregation between systems/products on CI tool --> risk of secret leakage, impacting other builds
3. Unrestricted or insufficiently restricted access to CI/CD tools --> risk of introducing unauthorized code, secret leakage, etc.
4. Lack or incorrectly implemented code signing --> SolarWinds case

Summing up, we are talking here about infosec basics - least privilege, integrity checks, etc. I just have a feeling that while talking about ci/cd security people tend to focus on security in the pipeline and not on security of the pipeline :)

Regards
Marcin "Ksl" Szydlowski

[jmanico]

"Developers pushing straight to Master branch" seems unfair. You can still do very good DevOps with trunk based development. gitFlow does not provide magic security that trunk based development does not.

https://trunkbaseddevelopment.com/

2/3/4 all seem very reasonable.

[Keeseeel]

Hey @jmanico thanks for feedback.

Sorry I was not clear - what I meant by 1) is that code is not reviewed what may introduce unauthorized changes. I simply believe that for any dev team bigger than 1 person, code reviews are necessary. I agree that it should not matter whether it is gitflow or trunk based development.

M

[jmanico]

That sounds a lot better to me @Keeseeel - I'm in full agreement!

[ducthinh993]

Great @Keeseeel,
I'm doing DevSecOps on banking for several years, it's really great to see someone pull this. Part of my job is to perform a security audit for any software development team using CI/CD to deploy their code to the infrastructure. So I would like to share some of my thought about some mistakes I've found during my career.

1/ Lack of CI/CD implement lead to pipeline integrity violation
This is the most wanted control I always look into. CI/CD is a guideline for the whole process so that it needs to protect from any integrity violation (by mistake or unauthorized change). As I know, there is 3 implement style currently:

• Define CI/CD within codebase: Very easy for developers to skip some part of the pipeline to deploy faster or for some others reason. It leads to some of the security assessments step often skipped during the development process. This kind of implement require a strong review/approval process which I mention in (2)
• Define CI/CD in other spaces and include to codebase: It better at some point, but developers still are able to attach malicious instructions to extend the pipeline and perform bad actions like print all ENV VAR in CI/CD run stage, which lead to exposing all secrets information.
• Define CI/CD in a separate system and trigger deployment via webhook: CI/CD pipeline is compliant with: integrity/network segmentation/separated AAA model. I often recommend DevOps team build CI/CD with is a methodology

2/ Lack of approval PIC when performing PR/MR
Since using git-flow becomes a standard for any developers, create a PR/MR to deploy to the environment requires not only a reviewer/approver from the Dev team but also need to require add-in others stake-holder. In the shared-responsibility security model, my PR/MR rules require: Dev leads (to make sure about code quality), QA (to get them to know they need to prepare the functional test), and Sec guys

3/ Lack of config management
A lot of DevOps teams store config and sensitive data in a vault, that's a good point. But wrong access and management model could lead to the sensitive leak

I am really happy to discuss more this topic.

Thanks,
BR

[Keeseeel]

Hey, Thanks for comment and all the great examples. Please ping me on Twitter @securityksl if you want to share some experiences.
Marcin

[infosecdad]

This is included in the upcoming A8:2021-Software and Data Integrity Failures. Thank you for the suggestions.