Xray的报表支持多种类型，主要包括：
漏洞报表，提供有关制品、内部版本和软件发行版（发行包）中的漏洞信息，以及诸如易受攻击的组件、CVE记录、CVSS分数和严重性之类的标准；
扩展资料：
一、背景
当前，随着比较常用的组件，如Tomcat、Docker、Kubernetes等陆续曝出存在高危漏洞，组件安全已成为业界日益关注的安全扫描新的重要分支。必须在DevOps流程中加强针对组件的安全扫描，这也是当前业界推荐的DevSecOps的重要组成部分。
JFrog Xray作为屡获殊荣的通用软件组成分析（SCA）解决方案，已得到全球开发人员和DevSecOps团队的信任，可以快速、连续地确定开源软件的安全漏洞和违反许可证合规性的行为。
JFrog持续努力，不断开发和创新，以为我们的客户提供更好的端到端DevSecOps体验。本文详细介绍了近期我们在JFrog Xray中添加的新功能，以帮助客户保持其准时发布的效率、质量，和安全性。
二、支持Conan包及C/C++的漏洞扫描
JFrog Xray最新支持扫描部署到JFrog Artifactory的Conan软件包以及C/C++应用构建。Conan是C/C++语言的依赖和程序包管理器，是开源的解决方案，可在所有OS平台上使用。它与所有构建系统（如CMake和Visual Studio等），以及专有系统集成在一起。Conan强大的功能是可以为任何平台和配置创建和管理预编译的二进制文件。
Xray支持以下四种Conan和C/C++构建扫描的主要场景：
Xray扫描从ConanCenter下载到Artifactory的软件包
Xray扫描基于Conan构建并已上传到Artifactory的程序包
如果您正在构建Conan软件包并将Xray集成到CI流程中，则Xray将扫描那些Conan的构建
即使您不使用Conan，Xray也会扫描您的C++构建
三、支持CVSS v3版本
为了在DevOps上取得成功，您选择的解决方案必须使您能够很好地完成一系列关键任务。让我们对比研究一下GitHub和JFrog，看看它们是否能够很好地完成您招聘所需完成的工作。
通用漏洞评分系统（CVSS）是一个开放的行业标准，用于评估软件安全漏洞的严重性。评分算法使用几种指标来分配和标记安全漏洞的严重性评分，而这些指标旨在逼近这些安全漏洞被利用的容易程度和威胁级别。
Xray从两个不同的来源收集评分和严重性：
NVD：美国国家漏洞数据库，包含已知漏洞及其各自的CVSS分数；
OS软件包安全咨询：某些开源 *** 作系统具有自己的安全跟踪系统，可以进一步分析 *** 作系统软件包中的漏洞。
CVSS评分的分数范围和严重程度
评分的目的是允许您根据威胁的级别确定响应和资源的优先级。分数的范围是0到10，其中最高的是10。CVSS v3还提供了严重性描述，
如下所示：
危急（Critical）
高级（High）
中级（Medium）
低级（Low）
未知（Unkown）
在Xray中设置的安全规则是根据CVSS v3得分或严重性级别（用于触发违规）来衡量的。Xray将继续支持CVSS v2评分，但仅在CVSS v3评分不可用时才使用它。
四、红帽安全扫描认证
JFrog Xray已通过Red Hat认证，成为其Red Hat Partner Vulnerability Scanner认证计划中的合作伙伴。通过认证可确保JFrog Xray识别的安全漏洞和许可证合规性数据准确，且与Red Hat软件包的预期结果一致，从而能够基于可信任的、经过认证的来源进行准确的风险评估。这意味着使用RPM软件包的企业可以放心地将JFrog平台用作其DevSecOps平台。
尽管自编码有了一些进展，但现在开发软件主要仍然得靠人工。然而，人非圣贤，孰能无过？因此，我们可以得到一个合理的推测：由人生产出来的产品和服务，必然包含某种形式的缺陷。所以，软件缺陷不可避免，并且是软件开发过程的固有部分。
软件缺陷是逻辑或配置上的错误，会导致系统产生我们不期望的行为。
软件应用程序中的一些主要和常见缺陷包括业务逻辑错误、复杂性问题、文件处理问题、封装问题、数据验证问题、身份认证和授权错误。
常见弱点枚举 (CWE) 清单描述了常见的软件和硬件弱点，会导致安全方面的相关问题。 该清单对可能存在的软件弱点进行了全面分类。
在业务研发过程中，我们通常通过比较内部质量和风险指标以及对需求、规范、标准和截止日期等方面的遵守程度，来衡量和评估软件质量等级的可接受度。
因此，我们应该可以得到这样一个结论：软件质量是主观的，受业务承诺、高级管理人员的参与情况和组织文化的影响。
软件开发中一个重要的关注点涉及到在预算、进度、范围、质量和安全性这些方面之间保持适当的平衡。一个方面的变化会影响其他方面。虽然都不希望改变计划，但这在软件开发生命周期中并不少见。这些场景反映了组织为了控制预算和进度，不得不在软件质量和安全性方面做出妥协。
软件质量并不总是软件的安全性指标。软件安全性的衡量标准，是在测试期间和生产部署之后发现的漏洞数量。软件漏洞是一类软件缺陷，潜在的攻击者经常利用这些漏洞，绕过授权，访问计算机系统或执行 *** 作。有时，授权的用户也会出于恶意，利用系统中这些未修补的已知漏洞。
这些用户还可能会输入不能通过校验的数据，无意中利用了软件漏洞，从而损害数据完整性和使用这些数据的功能的可靠性。对漏洞的利用会针对下面三个安全支柱中的一个或多个：机密性、完整性和可用性，它们通常称为 CIA 三元组。
机密性指保护数据在未经授权时不会被泄漏；完整性指保护数据在未经授权时不会被修改，以保证数据的真实性；可用性指系统在需要时可供授权用户使用，并拒绝未经授权的用户访问。了解软件错误和漏洞之间的区别，是为创建安全的软件和及时减少缺陷和漏洞的整体战略的关键。
软件漏洞
现在已公布的漏洞利用行为，以及OWASP十大、MITRE常见漏洞和暴露 (CVE) 列表、美国国家漏洞数据库和其他来源提供的见解都在讲软件漏洞。总体而言，这些信息强调了技术创新如何打破了所需的平衡，我们可以根据这些信息采取更有效的措施，在产品部署之前更好地检测和减少软件漏洞。
软件安全瑕疵越来越多，影响最大的因素是我们对软件安全性不思进取的态度、在软件安全性方面缺乏有效的最佳实践、软件开发人员和潜在攻击者之间的知识差异以及不安全的遗留软件。
由于威胁在不断变化，因此，在安全方面与时俱进的态度对于达成软件安全性很有必要。组织在开发和部署软件时，如果对安全的态度原地踏步，有可能会把内部合规跟有效、安全的软件开发周期过程混为一谈；对不断发展的威胁向量认识不足；从而无意中增加客户在各方面的风险。安全策略一成不变，只依赖内部合规来证明开发的软件很安全，这是短视的行为。
随着时间的推移，这种依赖性将导致利益相关者对组织开发安全软件的能力产生盲目的信心，并降低软件开发团队充分审查和应对不断变化的威胁的能力。若我所料不差，这些组织很可能没有有效的补丁管理程序，也没有在产品或解决方案实施过程中集成软件安全方面的设计原则。他们也不太可能添加安全相关场景的测试套件，或将软件安全的最佳实践纳入软件开发流程。
想要研发安全的软件，在研发生命周期中就应该应用软件安全方面的最佳实践。最佳实践涵盖安全设计原则、编码、测试、工具以及针对开发人员和测试人员的培训，有助于在将产品和解决方案部署到生产环境之前主动检测和修复漏洞。在合适的情况下，应用“故障安全”、“最小权限”、“深度防御”和“职责分离”等安全设计原则，可以增强应用程序的安全性。此外，还必须优先对开发人员和测试人员进行软件安全性方面的常规培训。
软件开发人员和潜在攻击者之间的知识差距正在扩大。这种现象的原因不尽相同，其中一些原因是心态、主要关注领域不同和缺乏学习机会。此外，一些软件开发人员对系统妥协持零和态度。这种心态与深度防御的安全设计原则背道而驰，并认为网络和设备漏洞实际上是“天国的钥匙”事件（译注：keys-to-the-kingdom，基督教典故，此处是指通过漏洞获得极大权限是漏洞发现者应得的）。因此，他们认为试图尽量减少妥协是徒劳的。有许多被爆出来的系统数据泄露事件，正是这种心态引发的后果，它们因缺少安全性或分层安全性不足，导致未加密的个人数据被盗。
这种“零和”心态，无意中助长了潜在攻击者通过各种技术深入到网络中进一步破坏生态系统的能力，从而可能获得对包含个人和业务数据的其他系统的访问权限。仔细审查代码是常见的深度防御措施，但一些软件开发人员未能有效利用。这些开发人员完全依赖自动代码扫描工具，而没有审查代码，或者只是粗略地审查代码。使用自动代码扫描工具并仔细审查代码才是一种有效的深度防御策略，可以在解决方案或产品部署到生产环境之前检测出漏洞。
软件开发人员和潜在攻击者有不同的优先级和重点领域。软件开发人员的重点领域包括实现业务逻辑；修复软件缺陷以满足质量要求；确保他们实施的功能或解决方案满足内部实用性、可用性和性能指标或服务水平协议 (SLA) 中的指标。显而易见，软件开发人员会在其主要关注领域获得专业知识。而潜在攻击者主要关注领域包括系统和软件行为分析，他们不断磨练技能以增加收入、满足好奇心、实现工具集、侦察和探索。所以同样地，潜在攻击者在其关注领域里也能获得专业知识。
潜在攻击者和软件开发人员之间的技能差异，让组织需要在软件安全方面持续地对软件开发人员进行培训。软件开发人员还必须了解当前的和不断拓展的攻击向量，并了解软件攻击面的概念，以避免在软件实现和修改过程中误入雷区。此外，软件开发人员必须转变观念，将软件安全原则和最佳实践纳入到软件开发生命周期中，它们与功能实现具有同等优先级。
在开发现在被称为“遗留”软件的那些年里，功能实现通常有最高优先级。对于许多软件供应商而言，软件安全跟功能的优先级不同，而且不是软件开发流程的一部分。在这种优先级安排以及威胁形势不断增长的长期影响下，其结果就是现在“遗留”软件中那些漏洞会被人发现和利用。为什么优先考虑功能实现，原因各不相同。
竞争、上市时间问题以及对软件安全缺乏关注，是组织不能遵循软件安全最佳实践和维持软件安全开发流程的主要原因。某些组织为了更好地保护“遗留”软件，给它们分配了资金和资源，在所需功能的实现上做出牺牲；并且由于持续关注在“遗留”软件的保护上，可能会丧失潜在的竞争优势。而其他组织通过检查软件漏洞来主动评估其“遗留”系统。尽管如此，在代码库被完全修补、升级到最新最安全或被废弃之前，遗留软件都将是漏洞利用方面的沃土。
结论
软件是潜在攻击者最常用的攻击媒介之一。因此，许多组织意识到，为了实现和维护安全的软件开发流程和基础架构，尽职尽责的调查非常重要。这些组织独立而又协同地为推进网络和软件安全领域的防御策略做出贡献。企业贡献包括：创建描述网络攻击阶段的安全模型和框架（例如洛克希德马丁公司的网络杀伤链），从而使组织能够规划相应的缓解措施；设立赏金计划，奖励查找漏洞，让安全研究人员和其他人可以因发现可利用的软件缺陷而挣到钱；对开源网络安全工具集的贡献；编写应用程序安全白皮书，描述最佳实践并促进软件安全向开发-安全-运维（DevSecOps）自然过渡。
不断发展的软件攻击向量使得我们不可能在生产部署之前消除所有软件漏洞。尽管如此，软件开发人员还是必须持续学习软件安全开发。也有人正关注于使用机器学习来检测软件漏洞，这将有助于更快、更有效地检测软件漏洞。然而，这种在专业领域采用机器学习的结果是否符合预期，目前还不确定。与此同时，各组织还是必须继续在同一战线上持续投入，共同抗衡潜在攻击者。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）