DevSecOps 原则和实践方式可与传统 DevOps 媲美，涉及多学科综合团队，他们共同努力实现安全、持续软件交付。 DevSecOps 开发生命周期是一个重复的过程，从开发人员编写代码开始，到触发构建，再到将软件包部署到生产环境并加以监控，以发现运行时的问题，不同之处在于，它在每一阶段均提供周密的安全防护。
DevSecOps 最佳实践应将安全性视为软件开发生命周期不可或缺的一部分。 每当开发出新功能和修复 Bug 时，都会重复该过程。 为了更快地进行开发和发布，开发人员依赖开源组件来完成项目。 现代化应用程序通常由高达 90% 的开源软件组成， 这难免会给组织带来以下问题：
依靠开发人员的报告和人工流程只能处理部分问题。 因此，保证安全性和合规性是 DevSecOps 流程的重要组成部分。
现有，开发人员、运营人员及安全人员的比例为 200:5:1。 这意味着由安全漏洞扫描工具发现的所有安全问题都需要由规模很小的安全团队来审查，而这个团队甚至可能连技术知识都不完备。 通过左移给开发人员和运营团队，让其也参与解决安全性和合规性问题，并在 SDLC 流程中尽早转移安全性问题，能够降低这一挑战的难度。
在 CI/CD 流水线尽早发现安全问题，以及在软件开发生命周期 (SDLC) 中实现安全和合规性策略的自动化，而不是使用人工流程，这一点至关重要。 此外，将安全事宜排除在 DevOps 之外的组织可能会面临与其发布密切相关的安全和合规性问题，因修复此类问题而造成额外成本。
DevSecOps 文化要求每个人都承担安全责任，参与到安全工作中去。 结合 DevOps 的最佳实践方式，每个开发团队都应该指派一名安全达人来领导团队中的安全和合规流程和行动，从而最大限度地提高所交付软件的安全性。
DevOps 的本质是尽可能地实现自动化，以防止人为错误；创建自动关卡，以防止将不稳定的代码投入生产。 从本质上讲，存在安全漏洞或不合规许可的代码都是不稳定代码。
向组织引入和实施 DevSecOps 需要在文化和运营方面进行变革。 包括： 安全培训、工具和资源。 以下是转变组织文化中的一些有用概念。
这些团队成员负责安全方面的整体工作，确保其在 DevOps 流水线中得以实施，并将其公开给团队的其他成员。 例如，开发团队安全达人将负责带领团队执行和使用：
QA 团队安全达人将执行：
DevSecOps 实践方式要求将安全工作融入 SLDC 中，而不仅仅是将软件发布到生产环境之前开展安全工作。 这意味着开发人员将安全扫描集成到构建流程以及其 IDE 环境中，以发现易受攻击的依赖项。
开发人员的数量达到安全专业人员的 200 倍。 专用的 IDE 插件可将安全数据直接引入开发人员已经使用的工具中，使其易于采用。 向开发人员介绍最佳实践方式，助其了解如何在编写代码时避免出现安全问题。
除了手动检查（例如代码审查）之外，还可以在 DevOps 流水线的每个阶段设置安全检查点，从而确定您的软件是否可以在下一阶段继续使用。 管理系统可以自动实施公司政策，并能够在没有干预的情况下采取相应的行动：
SDLC 各方面的问题可通过各种安全和合规性工具解决。 包括： 静态代码分析 (SAST)、软件成分分析 (SCA) 以及用于测试代码是否存在漏洞的不同方法（DAST 和 IAST）。 此外，还有一些工具，可以监控和保护生产环境中的二进制文件，避免攻击者通过您的代码或环境漏洞进行攻击。 理想情况下，为确保全面的 SDLC 安全性，团队应努力合理使用上述各种方法。
静态应用程序安全测试 (SAST) 工具可帮助您发现您开发的专有代码中的漏洞。 开发人员应了解 SAST 工具，并通过其推动开发过程的自动化。 这将有助于在 DevOps 周期尽早检测和修复潜在漏洞。
软件成分分析 (SCA) 工具可以对您的代码所依赖的开源组件进行管理和监控，避免存在许可合规性问题和安全漏洞。 了解正在使用哪些 OSS 组件及其依赖项，这是重中之重。 发现开源组件后，JFrog Xray 等 SCA 工具将提供有关许可的信息并明确是否存在与这些组件相关的任何已知安全漏洞。 高级 SCA 工具提供策略实施功能，可防止下载二进制文件，使构建失败和通知其他系统。
动态和交互式应用程序安全测试（DAST 和 IAST）工具测试正在运行的应用程序的公开接口，寻找漏洞和缺陷。 尽管 DAST 将应用程序视为一个黑匣子，但 IAST 使用结合了动态应用程序安全测试 (DAST) 和静态分析安全测试 (SAST) 技术的工具来提高应用程序安全测试的准确性。
容器运行时安全工具在其运行时环境中监控容器。 此类工具提供不同的功能，包括：不同级别的防火墙、基于行为分析识别异常等。
DevSecOps 最佳实践方式
为了跟上创新的步伐，开发人员越来越多地使用开源软件组件。在这种趋势催动下，软件成分分析 (SCA) 应运而生。 各公司正在努力管理和跟踪跨团队和站点的开源使用情况，需要一种更加自动化的方式。
开源软件通常占应用程序代码的 90%， 因此，一定要确保这部分代码得到妥善管理且安全无虞，这一点至关重要。
太多的公司忽视了开源组件的风险，而只关注其编写的代码。 这可能导致安全和许可违规事件，影响公司声誉，造成数百万美元的损失，受害者不乏 Equifax 和 Capital One 等公司。 SCA 解决方案可以解决这个问题。
SCA 可以对开源组件进行管理和监控，避免存在许可合规性问题和安全漏洞。 了解正在使用哪些 OSS 组件及其依赖项，这是重中之重。 识别组织中的 OSS 组件后，可以使用 SCA 工具了解各个组件，包括其许可信息、版本号以及是否存在相关的已知安全漏洞。
现在，OSS 组件在现代应用程序中占比高达 90%。 这意味着我们每天构建、部署和使用的大部分软件比以往任何时候都更有可能存在漏洞。 由于其开放性，黑客可以轻松访问其代码并查找漏洞。 开源软件不仅会带来漏洞风险，还会给组织带来复杂的许可合规性问题。 更有甚者，有些许可会提示“如果使用该组件，则需要使代码开源”。
理想情况下，您希望尽早在开发过程中扫描并识别所有 OSS 组件上的许可合规性和漏洞问题。 了解您在整个应用组合中具备哪些组件并对其进行跟踪是绝对必要的，而且还要实现自动化。 要维持正常的开发和发布进度，必须要将该流程集成到 CI/CD 流水线中。
一直以来，为了给整个 SDLC 提供保护，确保其安全投入生产，都需要运行代理来进行组件扫描。 如今，可使用各种不同解决方案来实现更高水平的安全性和进行合规性监控，此类解决方案直接集成到您的 IDE、制品库管理 工具、CI/CD 流水线中，甚至可以扫描您的容器镜像。 在开源安全和合规性监控中，使用原生集成的 SCA 解决方案效果最好。
高级 SCA 工具提供策略实施功能，支持对开源组件进行自动监控。 您可以对此类工具进行配置，使其根据扫描对象所处的环境，对发现的安全或合规性违规情况采取不同的措施。 举个例子：如果发现相同的漏洞，那么高度敏感应用程序的构建就会失败，而测试应用程序的构建却不会失败。 SCA 工具将您代码中的各个开源组件与您的策略进行比对，并根据结果自动触发不同类型的操作。
SCA 工具使用已知漏洞和许可的参考数据库，以此来比较您的应用程序正在使用的 OSS 依赖项。 数据库越全面，生产代码中出现已知漏洞或许可问题的风险就越低。
说到软件成分分析工具，必须考虑以下几点：
1. 技术支持： 其通用性如何以及是否支持贵组织使用的所有编码语言和包类型。
2. 生态系统集成： SCA 工具必须通过开箱即用的集成和丰富的开放 API 与制品库、IDE、包管理器、CI 服务器等集成。
3. 数据库： 全面的许可和漏洞数据库是为您提供最佳保障的必要条件。
完整的安全堆栈应包含以下工具：
- 动态应用程序安全测试 (DAST)
- 交互式应用程序安全测试 (IAST)
- 软件成分分析 (SCA)
- 静态应用程序安全测试 (SAST)
JFrog Xray 是一种 SCA 工具，专注于检测和消除开源安全漏洞和许可合规性问题，避免其影响您编写应用程序代码所依赖的 OSS 组件和依赖项。 OSS 组件在代码库中占比高达 90%，这意味着 Xray 在确保生产版本的稳定性和安全性方面可以发挥巨大作用。
这种方法可以在整个 SDLC 中为组织带来进益，包括： 通过尽早发现问题来提高质量，实现对专有和开源代码的可见性，通过在开发过程中尽早检测和修复漏洞来降低修复成本，最大限度地降低安全漏洞的风险，以及优化安全测试
您可以更好地集成 SCA 工具，但在安全扫描方面，却无法突破漏洞数据库给解决方案带来的限制。 使用没有收录最新漏洞的数据库，就像试图在人群中寻找素未谋面的人一样无从下手。 有些公司认为只要使用 MITRE 的通用漏洞列举 (CVE) 和国家漏洞数据库 (NVD)，就可以万无一失。 但许多安全专家坚持认为，依靠 CVE 和 NVD 获取漏洞数据已经不能满足当今需求了。
例如，以拥有最及时和最全面的漏洞情报服务之一 - VulnDB 而闻名的 Risk Based Security 公司，每年发现的漏洞数都超过了 CVE 和 NVD 所发现和编目的漏洞总和。 VulnDB 发现超过 249,155 个漏洞，覆盖 27,676 家厂商的产品，囊括数万个 CVE/NVD 未发现的漏洞，已经成为市场上最全面的解决方案。 对超过 2,000 个第三方库进行识别和监测。
JFrog Xray 与 VulnDB 紧密集成，通过其获得重要漏洞和许可合规性情报，获益匪浅。
首先，业内许多安全专家坚持认为，依靠 CVE 和 NVD 数据库获取漏洞数据已经不能满足当今需求了。 漏洞可能在 CVE/NVD 数据库公布之前已经存在很长时间，这段时间，不法分子可以分析这些漏洞并研究出如何利用其进行恶意活动。
您的 SCA 解决方案越早在数据库中收录漏洞，您就能越早为您的生产代码提供保护，避免出现这种漏洞。 许可类型和版本的检查也是这个道理。 您的合规或法律部门将拥有一套有关如何使用开源软件许可的指南。 通过对比最新的许可数据库，您能够最大限度地降低生产代码中出现非预期许可类型的风险，节省大量资金，省却繁复的处理工作。
确保 OSS 依赖项中的许可合规性是合规经理、法律团队和 CEO 等部门日益关注的问题。 没有人希望面对失败的审计、昂贵的知识产权或许可侵权案件。 了解正在使用什么 OSS、由哪些人开发，以及对哪些构建和发布非常重要。
我们都深刻认识到安全漏洞会造成的代价。 想想最近的 SolarWinds 数据泄露，还有更早之前让 Equifax 声誉严重受损的案例，两家公司因此损失数十亿美元。 不符合软件许可要求会带来巨大风险，可能会使您陷入复杂且代价高昂的知识产权之争。 某些许可的条款可能会提出要求，如果您使用其代码，您必须将整个应用程序代码开源。 我想没有哪个 CEO 希望免费奉上自己公司的“宝贝”吧。 对于某些公司而言，由于其软件性质，可能需要接受软件审计，而审计失败可能会受到高额罚款，这具体要取决于您所在的行业。
