今天是几号的博客

在现代软件开发环境中，开发团队经常会依赖于开源的第三方组件来节省时间和提高效率。这些组件本身是由开源社区(Github、Gitee)贡献者来开发，然而，这也带来了一些潜在的安全风险，特别是涉及到供应链安全(这些组件的开发者队安全队安全方面的了解几乎为0、恶意的供应链投毒风险)和第三方组件的质量问题(存在抄袭、开源许可证合规风险)。SCA（Software Composition Analysis）译为软件成分分析，通俗的理解就是通过分析软件包含的一些信息和特征来实现对该软件的识别、管理、追踪的技术。

应用安全正处于转型期，传统方法面临挑战。Gartner预测，到2026年，70%的平台团队将集成应用安全工具，显著高于2023年的20%。尽管组织采用了应用安全态势管理（ASPM）和分散的安全测试工具，但这常导致工具泛滥、误报增多和修复困难，反而增加了工作量、延缓了开发进度，并加大了风险。

随着现代软件开发实践的快速演变，特别是在敏捷开发和 DevOps 的推动下，应用程序安全变得更加复杂和动态，传统的安全措施往往难以跟上快速发布和部署的节奏，因此需要一种更综合的方法来管理应用程序的安全态势。应用程序安全态势管理（ASPM）这一概念是由Gartner在2023年提出的。ASPM的出现是为了应对现有的应用安全方法（如应用安全编排与关联（ASOC））在扩展性和应对不断演变的威胁方面的局限性。

接上篇文章所讲，使用开源组件，忽略开源许可证问题是存在合规风险的，但是关于什么场景下真实存在风险，以及什么样的风险？很多文章也没有讲的很明白，这些内容大部分都隐藏在晦涩难懂的许可证原文里面。通过一段时间的接触，包括收集资料、翻译许可证原文等学习，特此整理了一部分……

逛Github时经常看到项目README旁边，有个License tab，不知道大家是不是跟我一样，撇了一眼就过去了，不太清楚这个license具体作用，有点法律意识的朋友可能会意识到这个可能是版权声明，不过难免还是会有其他疑问：既然都开源了，怎么还有各种条件限制？除了GPL还有Apache、MIT等，这些"License"又有哪些区别呢？很多朋友可能像之前的我一样，二开项目或者使用第三方组件时直接拿来就用了，没有考虑过其背后的"风险"……

临近春节，笔者经过半年北漂，实习期间辗转几家公司，同时也接触了几种不同岗位，也算对安全有了个初步的了解目前在一家公司做安全开发相关实习，期间接触到一些比较有意思的技术，特此记录一下之前写一些小的工具，无论是Bash、Python还是Java，都是顶多几百行的工作量，感觉不到开发的魅力，也没有开发和安全相结合的感觉，后面在公司有机会写一下完整的系统，以及后续的部署发布，体验到了创造的魅力(增删改查 hah)