Gartner发布软件供应链安全指南:软件供应链攻击造成的损失将从 2023 年的460亿美元上升到2031年的1380亿美元

news2024/11/18 22:34:55

软件供应链安全是一个关键的风险和合规性问题,但大多数组织都以分散的方式处理它。缺乏一个包罗万象的框架会遗留安全漏洞。通过实施三支柱框架,安全和风险管理领导者可以确保广泛的保护。

主要发现

  • 对软件供应链的攻击给组织带来重大的安全、监管和运营风险。有数据显示,这些攻击造成的损失将从 2023 年的 460 亿美元上升到 2031 年的 1380 亿美元。

  • 在全球范围内,包括法律法规在内的合规要求以及非正式的行业指导正在实施,以迫使对软件供应链安全 (SSCS) 和应用程序安全风险采取更积极的应对措施。

  • Gartner 2023 年技术采用调查发现,近三分之二的组织报告称他们已经实施或正在实施 SSCS 计划。尽管如此,多起事件和指标表明,这些努力(通常在整个组织内缺乏协调)未能解决严重的安全漏洞。

建议

  • 制定一项协调战略来增强 SSCS,解决软件供应链框架的管理、创建和使用支柱中的所有风险因素。

  • 确定安全、软件工程、采购、供应商风险管理和其他方的利益相关者,教育他们了解所涉及的风险并支持他们采取必要的行动以减轻危险。

  • 与相关利益相关者协调,制定并实施计划,以弥补与SSCS工作相关的流程和工具的不足。

战略规划假设

到 2027 年,80% 的组织将在整个企业内采用专门的流程和工具来降低软件供应链安全风险,而 2023 年这一比例约为 50%。

介绍

破坏性攻击凸显了对软件供应链安全的迫切关注。这些攻击的估计成本高达数百亿美元,预计到 2031 年将增长 200%,达到 1380 亿美元(见图 1)。

图 1:全球软件供应链攻击年度成本

主要攻击面和风险包括:

  • 软件开发基础设施:通过渗透开发环境,攻击者将恶意软件整合到已部署的软件中。

  • 恶意代码:2023 年在 245,000 个开源软件包中发现了恶意软件,是 2019 年以来所有年份发现总数的两倍。

  • 开源漏洞:超过 90% 的专有代码包含开源依赖项,其中 74% 包含高风险依赖项。安全开发实践不足会增加代码中出现漏洞的概率。

  • 被遗弃且维护不力的开源依赖项:大约一半的开源依赖项在两年多的时间里没有开发活动,导致这些项目实际上被遗弃了。许多项目缺乏强大的维护者团队。如果在这些依赖项中发现漏洞,修复要么会被延迟,要么根本就不会出现。

软件供应链安全也是一个监管和合规问题,全球政府和行业都提出了要求。

Gartner 技术采用报告的约 59% 受访者表示,他们已经或正在部署 SSCS 措施。但Gartner 客户的研究表明,这些努力往往脱节。努力往往集中在问题的单一方面,组织利益相关者之间几乎没有协调。这种孤立的方法会导致重复和低效,以及糟糕的结果。许多组织正在重新考虑他们的软件供应链战略。在 Gartner Peer Connections 讨论中,67% 的参与者表示他们已经重新评估或计划重新评估他们的 SSCS 战略(截至 2024 年 5 月)。

软件供应链安全可以看作是一个涵盖三大支柱的框架:管理、创建和使用,如图 2 所示。通过实施这样的框架以及支持流程和工具,安全和风险管理领导者可以确保对问题做出协调响应,最大限度地减少保护盲点或漏洞,并降低整个软件开发和使用生命周期的风险。

分析

制定协调的 SSCS 战略

软件供应链安全是用于管理、创建和使用软件的一系列流程和工具,以减轻针对软件的攻击或其作为攻击媒介的使用:

  • 管理重点评估第三方软件的风险及其可接受性。

  • 创建专注于安全开发以及软件工件和开发流程的保护。

  • 使用通过验证、来源和可追溯性来确认软件的完整性。

图 2:软件供应链安全的三大支柱

为了实现软件供应链安全的最高有效性和效率,需要整个组织利益相关者的协调和参与。他们的信息需求以及他们为支持 SSCS 而采取的行动依赖于组织开发、使用和分发的软件的共享信息,以及相互关联和相关的流程。Gartner 建议组织在三大支柱上实施 SSCS 功能:

  • 软件开发中的监管包括根据已知的安全和运营风险主动评估和批准依赖项和软件工件,以尽量减少未来出现的问题。通过采取主动的方法并考虑各种风险,开发团队可以消除维护不善或不安全的工件,减少仅在项目中包含问题后才发现问题而导致的返工和摩擦。

  • 创造包括两个主要领域:

o   首先,它涉及在开发过程中管理依赖项和工件。虽然尽早评估这些元素(请参阅管理支柱)对于防止引入有问题的依赖项至关重要,但此支柱有助于通过软件物料清单跟踪软件包的使用情况,从而简化未来的漏洞修复。

o   其次,确保开发环境安全至关重要,包括保护开发人员工作站、存储库、版本控制、集成和构建系统以及部署流程。这可以防止对开发基础设施的攻击,近年来,这种攻击已导致严重的供应链漏洞。威胁建模和安全测试等活动(通常与核心应用程序安全活动相关)也通过在代码开发中推广“安全设计”方法增强了供应链安全性。

  • 使用增强了软件采购过程中传统的第三方风险评估。使用由采购和供应商风险管理团队进行,由 SSCS 的技术专家支持,涉及评估供应商软件安全措施并评估交付的代码是否存在策展中讨论的风险类型。此处收集的数据还可以简化对新出现的漏洞的事件响应。

管理

管理支柱涉及实施流程和工具,以便主动评估软件依赖项和其他工件,以识别与安全、许可、知识产权、供应链和运营相关的潜在风险。目标是通过仅评估和授权特定组件来防止使用不良组件。虽然这可能是一项复杂的任务,但好处是显而易见的,包括降低不安全或维护不善的依赖项带来的风险,并避免因使用不可接受的依赖项而导致的浪费精力和返工。

有不同的方法可以实现这一点:

  • 创建和维护可信存储库:这涉及建立一个已根据组织标准审查和批准的代码和工件存储库。开发人员无需从外部来源下载,而是从此存储库检索已批准的工件。但是,设置此存储库需要付出大量努力,包括建立基础设施、制定政策、评估代码和实施支持流程。对于资源有限的组织来说,这种方法可能不可行。

  • 自动管理工具和商业订阅:这些选项提供了一种更简单、资源密集程度更低的评估和控制工件的方法。一些软件组合分析和管理工具根据组织标准评估工件,并阻止下载不符合这些标准的软件包。这些工具结合使用专有研究和公开信息来评估与特定软件包相关的风险。或者,组织可以考虑订阅 Red Hat 或 Tidelift 等提供商的服务,这些服务支持维护和安全修复。

规划活动通常由开发和工程团队、应用程序安全团队和开源计划办公室进行。

尽管 Gartner 强烈建议使用此类评估,但目前很少有组织执行此类主动风险评估。这通常是由于缺乏内部先例、对所涉及风险的认识有限以及担心限制对依赖项的访问会阻碍开发过程。然而,忽视这些评估可能会导致安全或运营问题。例如,项目维护者或供应商可能不会优先考虑安全的开发实践,从而增加漏洞风险。此外,维护不善的代码可能会导致安全修复延迟或不可用,从而需要开发人员创建自己的修复程序或寻找替代依赖项。

管理行动行动计划

实施以下活动来支持管理支柱:

  • 评估依赖项和其他工件的安全性和操作风险,并在将其包含在代码中之前控制它们的使用。这可以通过受信任的存储库、在开发人员开源选择期间进行更动态的检查以及通过使用提供支持依赖项的商业订阅来实现。可以使用支持各种属性的工具来衡量风险,包括:

o   已知漏洞

o   法律上不受欢迎或限制性的许可

o   通过OSSF 记分卡等指标衡量运营和供应链风险。(记分卡包含对 19 种不同属性的评估,包括采用各种安全实践、分支保护措施、贡献者数量以及缺乏许可证。) 

  • 获取并评估与 SSCS 相关的工件,例如软件物料清单 (SBOM)、漏洞可利用性交换 (VEX) 披露,以及其他工件,例如来自商业供应商的安全软件开发实践证明。(有关更多详细信息,请参阅SBOM 的创新洞察。)

  • 测试代码和其他工件是否存在恶意或可疑代码(例如恶意软件、后门)。

创建

创建支柱包括在开发过程中评估和保护软件所采取的活动以及加强和保护开发环境本身的努力。

开发成果

工件(包括开源和商业依赖项、SDK、容器映像和专有代码)是在开发过程中导入或创建的。基于将恶意代码偷偷引入依赖项的攻击越来越普遍。下载和添加此类依赖项可以激活恶意软件,恶意软件可以传递给下游用户,使攻击者能够访问开发资源或其他不利结果。恶意内部人员还可以在开发过程中操纵代码,进行未经授权的更改或添加恶意代码。图 3 基于 ReversingLabs 进行的分析,概述了在开源依赖项中发现的越来越多的恶意组件。

图 3:开源软件中存在恶意代码

开发环境

开发流程涵盖开发人员的工作站、存储库和版本控制系统、集成和构建服务器、测试框架、部署工具等。攻击者通过网络钓鱼或其他形式的凭证盗窃等手段获取环境访问权限,从而发动了多起备受瞩目的供应链攻击。最终结果类似于针对带入系统的工件的攻击——引入恶意代码或未经授权访问资源,从而实现代码操纵、IP 盗窃和其他不良后果。

组织可以求助于各种框架和指导来帮助防范这些威胁。

Gartner 就该主题提供的指导——软件工程领导者如何降低软件供应链安全风险——概述了涉及代码保护、交付流程和操作环境的几项具体任务(见图 4)。 

图 4:减轻软件开发和交付中供应链安全风险的最佳实践

另一个资源关注的是相同的问题,即软件工件的供应链级别 (SLSA) ,这是开源社区和行业参与者正在开发的框架。SLSA 针对各种“轨道”(迄今为止,已定义构建轨道)进行阐述,这些轨道由不同的保证级别组成。例如,构建轨道提供四个级别: 

  • 0 级——无保证。

  • 1级——记录软件包构建过程的来源,帮助识别错误并提供文档以供将来参考。

  • 2级——由构建系统生成的加密签名来源,旨在检测构建过程后的篡改。

  • 3级——强化构建平台,用于检测构建过程中的篡改。

实施 SLSA 等框架需要工具来生成和验证所需的各种证明和记录。对于 SLSA,请考虑使用商业工具,或研究开源工具及其生态系统的使用情况。示例包括Sigstore (加密签名);元数据生成器(例如GitHub SLSA Generator )以及In-Toto ,它提供工作流和证明以支持生成和记录证明。    

安全软件开发框架 (SSDF)是NIST 基于经过验证的安全软件开发实践而制定的一套指南。它是评估软件开发实践(例如供应商的实践)的基准。供应商越来越多地被要求在采购和供应商风险管理活动中提供其遵守 SSDF 的证据。 

SSDF 包括与供应链安全相关的实践,例如“保护软件”,但它还涵盖应用程序安全的其他方面。其中包括设计安全软件、确保必要的组织结构和流程以支持应用程序和 SSCS,以及漏洞响应。

寻求全面指导以建立整体应用程序安全框架的组织可以使用 SSDF 作为模型。Gartner 还就此主题提供建议,包括《软件工程领导者应用程序安全指南》和《构建应用程序安全程序的指导框架》。

在创建支柱中,SSCS 任务通常由应用程序安全、开发和工程团队执行,有时也由其他安全成员执行,例如来自安全运营中心 (SOC) 或产品安全事件响应 (PSIRT) 团队的成员。这些团队必须合作实施一套实用且平衡的控制措施,尤其是针对开发人员工作站和开发流程中的访问控制。

控制不足或松懈会增加攻击成功的可能性。然而,虽然严格的控制可以防止攻击,但它们可能会阻碍开发人员的生产力和支持。因此,组织应该召集不同的团体来协商控制措施,以反映:

  • 正在开发的应用程序的总体风险和敏感性。

  • 攻击可能造成的潜在风险(例如数据泄露、法规不合规、业务影响)。

  • 开发管道控制所造成的延迟或其他负面影响。

自动化(利用开发基础设施来执行安全策略)可能大有裨益。在这种情况下,安全性定义了特定的策略来反映组织对给定应用程序的期望风险状况。使用自动化系统根据这些策略评估工件可确保快速评估和判断,从而有助于避免部署延迟。授权的工程人员可以处理例外情况,例如批准有问题的构建以快速解决生产中断。他们的活动应受到监控和记录,以供参考和审计。

创建行动计划

在创建支柱中,需要采取以下行动:

  • 重新评估依赖项的风险并控制其在开发中的使用。这是初步评估的次要措施,可确保未纳入未经授权的依赖项。此步骤还有助于跟踪依赖项的实际使用和部署,这对于事件响应至关重要。如果管理活动不足,这将成为主要的风险缓解活动,需要在构建过程中进行更严格的控制,这可能会导致开发过程中断。

  • 如果此时发现问题,请向开发人员提供指导,建议使用特定依赖项的替代版本来解决安全问题,或完全使用替代依赖项。有关使用中的依赖项的相对风险的信息,或依赖项的更新版本导致开发人员代码发生重大变化的可能性的信息可能会有所帮助。

  • 保护和加强开发环境和工件。这可以通过强大的身份验证和访问控制来控制对代码和其他资源以及开发基础设施的访问来实现。应执行职责分离和最小特权访问等原则。

  • 实施开发工具供应商提供的安全控制,例如策略定义和实施、分支保护以及服务器和进程的管理。理想情况下,访问软件工件和进程应通过存储库、服务器和测试框架等系统进行。这些系统充当代理,通过可以实施访问控制策略的系统来调解对代码和进程的访问。

  • 在需要直接访问系统或进程的情况下,请使用特权访问管理 (PAM) 等工具。PAM 提供必要的访问权限,同时保持所需的控制和监控,以最大限度地降低不当活动的风险。

  • 确保开发和运营团队积极参与定义和制定政策。所有利益相关者之间缺乏对开发环境中控制问题的规划和协商将不可避免地导致失败。

  • 实施流程和工具(如 SLSA),以便检测篡改或未经授权更改软件的企图。这些工具还可以报告工件来源和完整性。

  • 在构建过程中生成 SBOM(以及相关工件,例如 VEX 披露)。此信息应与内部团体(事件响应、产品安全等)和外部实体(业务合作伙伴、客户等)共享。

使用

使用支柱包括在购买之前或期间对商业和开源软件进行评估,以识别和降低风险。这一点很重要,因为有些案例中攻击者利用恶意代码破坏了商业软件,进而影响了客户。代码维护不善(包括使用过时或不安全的依赖项)表明存在重大技术债务,并对用户构成重大风险。这些评估还可以深入了解供应商所采用的应用程序开发和安全实践的严谨性。

Gartner 建议企业开展三项活动来识别和管理由于供应商应用程序安全流程不佳而导致的软件相关风险:

  • 将软件供应链和应用程序安全评估纳入现有的供应商风险管理计划。组织需要更深入地研究供应商的应用程序安全实践。上述 NIST 框架SSDF可用于评估供应商的努力。安全和风险管理领导者应与采购和供应商风险管理团队合作,对供应商是否遵守此框架或类似框架进行评估。 

  • 要求软件内容和组成透明,包括开源依赖项和其他商业代码。软件内容可以通过 SBOM 确定。数据库(包括OSSF Scorecard项目等开源项目以及专有产品)可以提供有关各个依赖项的信息。买家应评估这些信息,并选择具有强大应用程序安全实践的供应商。 

  • 采用专门的测试和评估来搜索软件包中的恶意代码。虽然这是适用于所有类型的软件包应用程序的最佳做法,但它对于高风险系统尤其重要,因为恶意代码的影响更大。在部署之前结合使用专门的工具对软件进行沙盒处理可以帮助识别恶意代码。渗透测试等更传统的方法也可以提供帮助。在进行此类评估之前,应咨询法律顾问,以确保不会发生违反许可协议或控制法律法规的情况。

使用行动计划

为支持使用支柱应实施的具体活动包括:

  • 实施流程和技术来接收、分析和存储 SBOM、VEX 漏洞披露和其他 SSCS 相关工件。这样做将确保可以轻松访问这些工件及其所包含的信息,以进行风险管理并评估新漏洞的影响。

  • 制定政策,概述与商业和开源软件相关的可接受风险以及例外情况的程序。考虑以下因素:

o   是否存在漏洞,以及在什么情况下可能允许使用有漏洞的代码。

o   许可证条款不为组织所接受(需要法律顾问)。

o   指示代码总体健康状况和声誉的属性(如更新频率、维护者社区规模、遵守安全软件开发实践)。有关相关数据,请参阅OSSF Scorecard项目。 

  • 对于商业或合同软件开发,遵守安全软件开发流程的证明。SSDF 是一个全面的例子。其他替代方案包括《软件开发人员验证最低标准指南》和ISO/IEC 27034-1:2011 信息技术 - 安全技术。在适用的情况下,考虑特定行业或地区的指导或法规。  

  • 跟踪应用程序(内部开发和外部获取)中使用的依赖项(开源和商业),以快速识别可能受影响的系统。

  • 对代码进行主动测试(二进制分析、渗透测试等),尤其是对敏感或高风险系统。法律顾问是必要的,因为许可协议和当地法律可能会限制测试范围。

确定利益相关者

如图 5 所示,有效的 SSCS 涵盖组织的多个部分。跨组织协调和信息共享可通过确保一致遵循 SSCS 标准来改善结果。各个团体都可以从共享信息中受益。例如:

  • 采购和供应商风险管理团队在评估供应商和软件的风险时可以利用应用程序安全团队开发的开源风险数据。

  • 当运营安全和事件响应团队能够轻松访问软件清单(商业和专有)及其所包含的依赖项并响应依赖项中的漏洞报告时,他们的效率会大大提高。

  • 为了确保信息共享的便利及其在工作组之间的一致性,应该考虑一个通用的存储库,尽管工具和功能各不相同,使这项任务变得困难。

图5:软件供应链安全跨组织协调

采用流程和工具

鉴于组织使用和创建的软件数量庞大,以及为支持改进风险管理而需要分析和评估的数据量,某种程度的工具是不可避免的。不幸的是,市场很复杂,许多供应商(和几个开源项目)提供产品和工具来支持 SSCS 生命周期的不同元素。

相对较少的供应商能够提供完全涵盖 SSCS 框架所有支柱的综合解决方案,因此尽管更加整合的解决方案可以带来诸多好处(更容易的信息共享、简化的供应商管理等),但买家通常需要考虑多种工具来解决问题的不同部分。

评估和采购工作应从评估不同阶段对特定组织的重要性开始。例如,内部开发相对较少或使用外部依赖关系较少的组织可以降低专注于策划和创建阶段的功能和工具的优先级,转而强调在使用阶段对商用现成软件的评估和管理。

了解了相对优先级后,买家可以开始确定最符合其需求的供应商。鉴于市场的复杂性和不同工具功能的变化,咨询 Gartner 分析师有助于确定最符合特定组织需求的供应商。然后,买家可以继续评估最有可能完全满足其独特需求的工具。

在评估工具时,请考虑框架不同支柱的行动计划中概述的功能和任务(如上所述),作为评估标准的起点。问题的跨组织性质将推动来自多个利益相关者的代表的需求,以确保充分考虑功能。这些人还可以提供对其他要求的见解,例如将 SSCS 工具集成到其他组织系统(例如,软件资产管理、应用程序安全和 ASPM、SIEM 等运营安全系统以及 IT 服务管理工具)的需求。

Gartner 的其他研究可以提供有关 SSCS 领域内供应商的见解。例如:

  • 软件工程领导者如何减轻软件供应链安全风险提供了用于秘密扫描和管理、可信组件注册表和工件签名等功能的商业和开源工具列表。

  • SBOM 的创新洞察包含支持 SBOM 生成和管理功能不同方面的工具列表和链接。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/1896643.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

Twitter群发消息API接口的功能?如何配置?

Twitter群发消息API接口怎么申请?如何使用API接口? 为了方便企业和开发者有效地与用户互动,Twitter提供了各种API接口,其中Twitter群发消息API接口尤为重要。AokSend将详细介绍Twitter群发消息API接口的功能及其应用场景。 Twit…

船舶雷达与导航中M7/8防水插座应用优势

船舶雷达与导航系统是船舶安全航行的重要组成部分,而7/8防水插座在这些系统中起着至关重要的作用。其中防水MIN-change 7/8"航空法兰插座成型预铸电缆式、组装式、面板式法兰座、T-型三通可选 7/8防水插座的电气性能 7/8防水插座因其优良的电气性能而被广泛应…

【matlab 路径规划】基于改进遗传粒子群算法的药店配送路径优化

一 背景介绍 本文分享的是一个基于订单合并的订单分配和路径规划联合优化,主要背景是骑手根据客户需求,从药店取药之后进行配送,配送的过程中考虑路径的长度、客户的服务时间窗、车辆的固定成本等要素,经过建模和优化得到最优的配…

收银系统源码-营销活动-幸运抽奖

1. 功能描述 营运抽奖:智慧新零售收银系统,线上商城营销插件,商户/门店在小程序商城上设置抽奖活动,中奖人员可内定; 2.适用场景 新店开业、门店周年庆、节假日等特定时间促销;会员拉新,需会…

【漏洞复现】万户协同办公平台——反序列化

声明:本文档或演示材料仅供教育和教学目的使用,任何个人或组织使用本文档中的信息进行非法活动,均与本文档的作者或发布者无关。 文章目录 漏洞描述漏洞复现测试工具 漏洞描述 万户协同办公平台ezEIP是一个综合信息基础应用平台,…

14-11 2024 年的 13 个 AI 趋势

2024 年的 13 个 AI 趋势 人工智能对环境的影响和平人工智能人工智能支持的问题解决和决策针对人工智能公司的诉讼2024 年美国总统大选与人工智能威胁人工智能、网络犯罪和社会工程威胁人工智能治疗孤独与对人工智能的情感依赖人工智能影响者中国争夺人工智能霸主地位人工智能…

上海时尚新品发布会,可以邀请哪些媒体

传媒如春雨,润物细无声,大家好,我是51媒体网胡老师。 在上海举办时尚新品发布会时,可以邀请的媒体类型多样,以下是一些建议的媒体类型及其特点: 一、平面媒体 报纸: 《文汇报》:上…

【带你全面了解 RAG,深入探讨其核心范式、关键技术及未来趋势】

文末有福利! 大型语言模型(LLMs)已经成为我们生活和工作的一部分,它们以惊人的多功能性和智能化改变了我们与信息的互动方式。 然而,尽管它们的能力令人印象深刻,但它们并非无懈可击。这些模型可能会产生…

python-图像旋转(赛氪OJ)

[题目描述] 输入一个 n 行 m 列的黑白图像,将它顺时针旋转 9090 度后输出。输入: 第一行包含两个整数 n 和 m,表示图像包含像素点的行数和列数。1≤n≤100,1≤m≤100。 接下来 n 行,每行 m 个整数,表示图像…

【FreeRTOS】同步与互斥通信-有缺陷的互斥案例

目录 同步与互斥通信同步与互斥的概念同步与互斥并不简单缺陷分析汇编指令优化过程 - 关闭中断时间轴分析 思考时刻 参考《FreeRTOS入门与工程实践(基于DshanMCU-103).pdf》 同步与互斥通信 同步与互斥的概念 一句话理解同步与互斥:我等你用完厕所,我再…

【Python学习笔记】菜鸟教程Scrapy案例 + B站amazon案例视频

背景前摇(省流可以跳过这部分) 实习的时候厚脸皮请教了一位办公室负责做爬虫这块的老师,给我推荐了Scrapy框架。 我之前学过一些爬虫基础,但是用的是比较常见的BeautifulSoup和Request,于是得到Scrapy这个关键词后&am…

【2023ICPC网络赛I 】E. Magical Pair

当时在做洛谷U389682 最大公约数合并的时候我就想到把每个质因子分解出来然后跑高维前缀和,但是那一道题不是用这个方法,所有我也一直在思考这种做法是不是真的有用。因为昨天通过2024上海大学生程序设计竞赛I-六元组计数这道题我了解到了不少关于原根的…

印章谁在管、谁用了、用在哪?契约锁让您打开手机一看便知

“印章都交给谁在管”、“哪些人能用”、“都有哪些业务在用”…这些既是管理者最关心的印章问题也是影响印章安全的关键要素。但是公司旗下分子公司那么多,各类公章、法人章、财务章、合同章一大堆,想“问”明白很难。 契约锁电子签及印控平台推出“印章…

【FreeRTOS】同步互斥与通信 有缺陷的同步示例

目录 1 同步互斥与通信1.1 同步互斥与通信概述1.2 同步与互斥的概念1.3 同步的例子:有缺陷1.4 freertos.c源码3. 互斥的例子:有缺陷4. 通信的例子:有缺陷5. FreeRTOS的解决方案 1 同步互斥与通信 1.1 同步互斥与通信概述 参考《FreeRTOS入门…

滚动表格(vue版本)【已验证可正常运行】

演示图 注&#xff1a;以下代码来自于GPT4o&#xff1a;国内官方直连GPT4o 代码 <template><div><div class"alarmList-child" ref"alarmList" mouseenter.stop"autoRoll(1)" mouseleave.stop"autoRoll()"><div…

Debezium报错处理系列之第111篇:Can‘t compare binlog filenames with different base names

Debezium报错处理系列之第111篇:Cant compare binlog filenames with different base names 一、完整报错二、错误原因三、解决方法Debezium从入门到精通系列之:研究Debezium技术遇到的各种错误解决方法汇总: Debezium从入门到精通系列之:百篇系列文章汇总之研究Debezium技…

【笔记】redis和session的关系

把这句注释掉之后变成了空指针 新用户/老用户的id都登不进页面

k8s-第四节-Service

Service Service 通过 label 关联对应的 PodServcie 生命周期不跟 Pod 绑定&#xff0c;不会因为 Pod 重创改变 IP提供了负载均衡功能&#xff0c;自动转发流量到不同 Pod可对集群外部提供访问端口集群内部可通过服务名字访问 创建 Service kubectl apply -f service.yamlkub…

Maven 分模块设计与开发 继承

介绍 在 Maven 中进行分模块设计&#xff08;multi-module project&#xff09;&#xff0c;可以帮助将一个大型项目分解为更小、更易管理的模块。这种设计方式有助于提高项目的可维护性、复用性和团队协作效率。 继承关系 目录结构 引入父Maven 父坐标 在子项目中引入父亲…