网络基础设施通常被视为事后才想到的事情：“我们在云端，我们有 Kubernetes，某个地方有防火墙。”但这种心态很快就会变得危险，尤其是当应用程序本身成为薄弱环节时。
代码与网络基础设施之间的盲点
安全责任常常被错配。开发人员专注于交付功能；他们想当然地认为基础设施团队已经做好了安全保障。与此同时，基础设施团队却认为应用程序的设计已经非常牢固。这种脱节造成了盲点，攻击者很容易利用这个盲点。
真实世界的例子： A CI/CD pipeline 错误配置暂存环境一个本应隔离的内部服务却暴露在网络中。应用程序部署时绑定了开放端口，且没有出口限制。发布前没有人扫描环境中是否存在暴露的服务。这并非理论上的问题，而是基本安全网络设计在实践中的失败。
失败之处：
- 无出口控制： 一旦服务启动，它就可以与任何事物对话。
- 分期时无暴露扫描： 开放的端口未被注意到。
这说明了为什么网络基础设施本身是不够的。应用程序和 pipeline 还必须执行安全边界。
在这种情况下，网络安全是什么？它不仅仅是防火墙规则或私有子网。它还涉及了解代码在运行时环境中的行为方式、在部署前扫描暴露情况，以及在构建期间强制执行严格的网络行为。
这正是网络感知 AppSec 的用武之地。它不止于 扫描源代码。 它研究代码、基础设施和 CI/CD 相交以揭示现实世界的网络风险。
DevSecOps 悖论：“但我们有防火墙”不是网络安全
你位于 VPC 后面。有防火墙规则。容器位于私有子网中。但当应用暴露敏感接口时，这些都不重要了。
例子：
- S3 存储桶被错误配置为公共存储桶，但从技术上讲，它位于私有网络“后面”。
- 通过 Kubernetes 上的错误路由入口公开的内部 API。
认为网络基础设施能够防范应用程序级错误的想法已经过时了。安全的网络设计只有在应用程序代码遵循边界的情况下才有效。
当应用程序代码破坏安全网络设计时
一些最大的安全漏洞都是从应用程序代码中的微小疏忽开始的：
绑定到 0.0.0.0： 这会将服务暴露在所有接口上，即使是在仅供内部使用的容器中。这在开发环境中可能没问题，但如果投入生产环境，它会毫无预警地将私有服务变成公开服务。
🔒 安全替代方案：
- 第三方包 默认启动 HTTP 服务器。这些通常是为了方便使用和提供功能而添加的，但却为意外访问打开了方便之门。
- 硬编码令牌 可通过内部路由访问。如果攻击者到达一个内部服务，他们可能会提取令牌并访问其他服务。
这些不是极端情况。它们在现实中发生 pipeline在现实环境中。网络基础设施无法避免代码中不安全的默认设置。
CI/CD Pipelines：网络基础设施的隐藏威胁
您的构建 pipeline 可能是你的堆栈中权限最高、安全性最低的部分。攻击者的目标是 CI/CD 环境不仅会破坏构建，还会更深入地影响您的基础设施。
攻击流程：
→ 破坏 CI 运行器或 GitHub Action。
→ 通过开放的网络路径连接到内部服务。
→ 重复使用存储或硬编码的令牌。
→ 扫描内部 IP 范围以发现实时服务。
→ 横向移动以访问关键服务或数据库。
这一运动通常是通过以下方式实现的：
- 拥有过多权限的跑步者 允许横向移动。
- 凭证重用 工作或项目之间。
- 不受限制的出口 这使得受损的工作可以与任何内部主机进行通信。
解决方案？作业隔离、零信任网络访问、运行人员的最低权限以及严格的出口策略。如果没有这些，安全的网络设计就会被自动化工具破坏。
解决办法是什么？作业隔离、零信任网络访问以及运行器中的严格出口策略。
潜入 CI/CD Pipeline漏洞
您的 CI/CD pipeline 可能是您安全链中最薄弱的环节，攻击者也深知这一点。了解中毒是如何发生的 Pipeline 执行（PPE）将可信自动化变成黑客的游乐场，您可以采取哪些措施将他们拒之门外！
开放服务、暴露端口和网络安全风险
集装箱运输速度很快，但运输往往不安全：
- Redis 在默认端口上运行。
- 内部代理仍在 8080 上监听。
- 无意中向听众介绍的套餐。
一个良好、安全的网络设计会假设这些情况会发生。它会默认阻止这些情况，并在出现时发出警报，并将暴露端口验证作为持续集成 (CI) 的一部分。
将安全网络设计集成到开发工作流程中
AppSec 不再只是静态代码分析。为了捕捉真正的风险，你需要 结合 SAST/SCA 具有网络扫描和曝光验证功能。
实际流程： 构建 → 静态扫描 → 基础设施扫描 → 验证暴露端口 → 执行策略
计费示例： 使用 GitHub Actions 规则来使不必要的端口暴露的构建失败。
这个简单的规则通过将端口扫描集成到 CI 流程中来强制执行暴露卫生。
首推最高性价比 DevSecOps最佳实践: 结合 SAST 通过基础设施扫描来发现错误配置，从而检测代码级漏洞。这种双层方法提供了现代安全网络设计所需的可视性。
这就是 DevSecOps 的威力。它让网络安全成为你实际工作的一部分。 pipeline.
从 Guardrails 架构：构建安全的网络基础设施
开始在开发环境中强制执行安全默认值，而不仅仅是在生产环境中。 Guardrails 是一个好的开始，但架构级的控制使安全性可持续。
具体步骤：
- 阻止 0.0.0.0 绑定 变异准入网络hooks 在 Kubernetes 中。这可以防止不安全的服务暴露。
- 默认拒绝来自构建容器的出站流量，以避免未经授权的数据流。
- 绝大部分储备使用 OPA 守门人 执行网络分段、服务白名单或强制入口注释等策略。
将策略代码化，作为一种可复用且可版本控制的策略。通过编纂规则（例如，拒绝所有未带有 networkPolicy 标签的服务），团队可以在开发、测试和生产环境中应用一致的、特定于环境的策略。
策略即代码不仅可扩展，而且可审计、可移植，并可直接与 CI/CD 以及基础设施即代码工作流程。这使其成为实施全生命周期网络安全的关键。
良好的网络基础设施无法挽救糟糕的应用程序代码
您的防火墙不会阻止公开调试路由的 Node.js 服务器。您的 VPC 也不会阻止启动内部代理的软件包。如果应用公开了内部代理，网络就会允许它。
这是基本的事实：当应用程序代码违反规则时，安全网络设计就会失败。
没有代码纪律的网络安全算什么？
这是一个虚假的承诺。网络安全只有在应用程序、 pipeline以及基础设施都朝着同一个方向发展。然而，安全实践往往侧重于边缘，而非内部。
多孔 CI 作业可能会无意中为攻击者提供网络立足点，建立具有过多权限或没有出口限制的运行者作为后门。
开源软件包中的不安全默认值、绑定到所有接口的服务、嵌入式 HTTP 服务器或未经验证的内部代理会悄无声息地快速破坏您的安全网络设计。
传统的假设同样危险。在云原生架构中，将某些内容视为“内部”或“私有”的想法是误导性的。在现代环境中，“内部”通常意味着“只要知道 IP 即可访问”。
如果没有严格的界限和主动的扫描，小错误就会产生连锁反应：
- 开发中的调试接口使其进入暂存阶段。
- 监控端口因错误配置的入口而暴露。
- 由于没有人检查默认绑定，因此内部工具向全世界开放。
如果可以通过 package.json 依赖项绕过网络安全，那么网络安全又是什么呢？
真正的安全网络设计始于代码，并贯穿于 pipeline。纪律不是可选的；它对于确保整个堆栈可防御至关重要。
Xygeni 如何通过 AppSec 帮助保护网络基础设施
西吉尼 带来网络感知 AppSec 直接进入您的 CI/CD pipelines实时检测风险行为，并自动执行预防策略。它不仅仅依赖于代码扫描，还能观察真实的构建活动，从而捕捉静态工具遗漏的漏洞。
Xygeni 的功能：
- 在构建期间检测 0.0.0.0 绑定： 如果某个服务绑定到所有接口，Xygeni 会标记该问题并阻止合并。它会发出上下文警报，其中包含文件位置、服务名称和修复指南。
- 识别默认公开的内部端口： 即使服务不打算公开，Xygeni 也会分析 Dockerfiles 和运行时配置来检测应该被阻止的开放端口。
- 警告过于宽松的工作： Xygeni 会扫描您的 CI 配置，查找权限过高的运行器、广泛的网络访问权限以及跨作业重复使用的令牌。它会将这些信息与实际的服务暴露情况关联起来，以确定风险的优先级。
凭借这些功能，Xygeni 通过自动化来强制执行安全网络设计，在不安全的工件进入生产之前，在开发过程中为团队提供早期可操作的反馈。
最后的想法：一切从代码开始，而不是防火墙
你不能在最后阶段才把网络安全放在首位 pipeline 并期望它能够持续有效。真正的安全，真实、有弹性、全栈的安全，从代码编写的那一刻开始，并贯穿构建、测试和部署。
每一层都很重要：
- 如果代码默认公开接口，则网络已经受到威胁。
- 如果构建过程没有验证开放端口，则暴露就会溜走。
- 如果 pipeline 允许过度许可的工作，周长变得无关紧要。
在持续部署、快速迭代和严重依赖开源的世界中，假设网络将修补不安全的默认值是一种危险的幻想。 “网络安全并非始于防火墙。它始于你的代码、你的构建和你的 pipeline设立的区域办事处外，我们在美国也开设了办事处，以便我们为当地客户提供更多的支持。“
这意味着将网络感知的 AppSec 视为开发的核心功能。这意味着尽早集成安全检查，并将安全网络设计强制执行为团队代码交付的一部分。 没有捷径，没有假设，只有纪律、可视性和自动化，端到端。
网络安全不能强加于人。它必须成为你编写代码、构建软件和部署的一部分。让它具备网络感知能力，让它默认安全。不要再想当然地认为网络能够抵御恶意攻击。cis代码中的离子。
