首页 文章 精选 留言 我的

精选列表

搜索[检测工具],共1093篇文章
优秀的个人博客,低调大师

GrammaTech 推出 API bug 检测工具,美国国土安全部赞助

安全测试解决方案公司GrammaTech 推出了一个名为 Swap Detector 的开源工具,可用来检测应用程序编程接口(API)使用错误。 Swap Detector 是美国国土安全部科技局静态工具分析现代化项目(Static Tool Analysis Modernization Project,STAMP)赞助的研究项目的一部分,可改善 DevOps 团队的应用安全测试。该工具可以让开发人员和 DevOps 团队能够识别由于交换函数参数导致的错误(这些错误也可能存在于部署的代码中)。 GrammaTech 研究副总裁 Alexey Loginov 称,“传统的静态分析技术并没有利用开源领域现有的代表无错误编码实践的大量信息。通过Swap Detector,我们将大数据分析技术,也就是我们所说的 Big Code分析,应用到 Fedora RPM 开源库中,以确定正确的 API 使用基准。这让我们开发的错误检测能力远远超过了传统程序分析方法的可扩展性和准确性。” Swap Detector 接口集成了各种静态分析工具,例如 Clang Static Analyzer、Clang-Tidy 和 PyLint。最初,Swap Detector 的研发侧重于C/C++ 程序方面,但如今其已适用于其他语言的程序,特别是对解释型和非编译型的语言来说非常有利。 Swap Detector 采用多种错误检测技术,并将它们层叠在一起以提高准确性。例如,将调用站点中使用的参数名称与相应声明中使用的参数名称进行比较。此外,它还使用了“Big Code”技术,应用从大量代码样本中收集的已知良好 API 使用模式的使用情况的统计信息,并将统计上异常的使用情况标记为潜在的错误。为了提高报告警告的精度,Swap Detector 还对这两种技术的输出采用了减少假阳性的策略。

优秀的个人博客,低调大师

Android内存优化7 内存检测工具1 Memory Monitor检测内存泄露

上篇说了一些性能优化的理论部分,主要是回顾一下,有了理论,小平同志又讲了,实践是检验真理的唯一标准,对于内存泄露的问题,现在通过Android Studio自带工具Memory Monitor 检测出来。性能优化的重要性不需要在强调,但是要强调一下,我并不是一个老司机,嘿嘿!没用过这个工具的,请睁大眼睛。如果你用过,那么就不用在看这篇博客了。 先看一段会发生内存泄露的代码 public class UserManger { private static UserManger instance; private Context context; private UserManger(Context context) { this.context = context; } public static UserManger getInstance(Context context) { if (instance == null) { instance = new UserManger(context); } return instance; } } public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); UserManger userManger = UserManger.getInstance(this); } } 代码很简单,就是一个单利模式泄露的场景,我们现在的关心的不是代码本身,而是如何将代码里面的内存泄露给找出来。但是对于上面的代码发生内存泄露的原因还是有必要提一下。 上篇博客说了,内存泄漏产生的原因是:当一个对象已经不需要再使用了,本该被回收时,而有另外一个正在使用的对象持有它的引用从而就导致,对象不能被回收。这种导致了本该被回收的对象不能被回收而停留在堆内存中,就产生了内存泄漏。 在上面的代码中,发生泄露的不是UserManger,而是MainActivity,UserManger中有一个静态成员instance,其生命周期和应用程序的生命周期一致,当退出应用时,才能被销毁,但是当GC准备回收MainActivity时,结果呢MainActivity的对象(this)在被UserManger所引用,UserManger本身又不能被干掉,所以就发生了内存泄露。 monitors.png Memory Monitor是Android Monitors中的一种,Monitors主要包括四种,Memory Monitor ,CPU Monitor ,NetWork Monitor, GPU Monitor ,今天介绍的是Memory Monitor ,其他的Monitor,在后面也准备讲。 Memory Monitor界面 Memory Monitor.png 图中水平方向是时间轴,竖直方向是内存的分配情况 图中深蓝色的区域,表示当前正在使用中的内存总量,浅蓝色或者浅灰色区域,表示空闲内存或者叫作未分配内存。 内存分析的工具栏,从上向下一共4个按钮,依次是: 终止检测的开关,没什么实质性的作用 就是手动调用GC,我们在抓内存前,一定要手动点击 Initiate GC按钮手动触发GC,这样抓到的内存使用情况就是不包括Unreachable对象的(Unreachable指的是可以被垃圾回收器回收的对象,但是由于没有GC发生,所以没有释放,这时抓的内存使用中的Unreachable就是这些对象) (Dump Java Heap)点击可以生成一个文件(包名+日期+“.hprof”),可以记录摸一个时间点内,程序内存的情况。获取hprof文件(hprof文件是我们使用MAT工具分析内存时使用的文件),但这里直接产生的文件MAT还不能直接使用,需用转换成标准的hprof文件。可以使用AndroidStudio转换或者用hprof-conv命令转化,网上可以查到 开始分配追踪,第一次点击可以指定追踪内存的开始位置,第二次点击可以结束追踪的位置。这样我们截取了一段要分析的内存,等待几秒钟AndroidStudio会给我们打开一个Allocation视图(感觉和MAT工具差不多,不过MAT工具更加强大,我们也可以获取hprof文件,使用MAT来分析) 回到我们的程序,多点击几次GC,看一下这个应用的内存使用情况。 内存使用情况.jpg 可以看到现在已经分配的内存有19.68M,我把手机旋转一下,在看。 旋转后内存使用情况.png 可以看到现在的内存使用量是21.09M,还是一样的界面,却多了1.41M!!!这很关键。 接下来,我们找一下,哪里发生了泄露。点击Dump Java Heap,生成快照文件tool.test.memory.memoryleak_2016.11.13_21.38.hprof,Android Studio 自动弹出HPROF Viewer来分析它。 快照文件分析.png 现在介绍一下HPROF Viewer的用法 HPROF Viewer查看方式 左上角两个红框,是可选列表, 分别是用来选择Heap区域, 和Class View的展示方式的. Heap类型分为: App Heap -- 当前App使用的Heap Image Heap -- 磁盘上当前App的内存映射拷贝 Zygote Heap -- Zygote进程Heap(每个App进程都是从Zygote孵化出来的, 这部分基本是framework中的通用的类的Heap) Class List View -- 类列表方式 Package Tree View -- 根据包结构的树状显示 我通常点击App heap下面的Classs Name把Heap中所有类按照字母顺序排序,然后按照字母顺序查找。 HPROF Viewer主要分ABC三大板块 板块A:这个应用中所有类的名字 版块B:左边类的所有实例 板块C:在选择B中的实例后,这个实例的引用树 A板块左上角列名解释 列名 解释 Class Name 类名,Heap中的所有Class Total Count 内存中该类这个对象总共的数量,有的在栈中,有的在堆中 Heap Count 堆内存中这个类 对象的个数 Sizeof 每个该实例占用的内存大小 Shallow Size 所有该类的实例占用的内存大小 Retained Size 所有该类对象被释放掉,会释放多少内存 B板块右上角上角列名解释 列名 解释 Instance 该类的实例 Depth 深度, 从任一GC Root点到该实例的最短跳数 Dominating Size 该实例可支配的内存大小 B板块右上角有个"的按钮, 点击会进入HPROF Analyzer的hprof的分析界面: Analyzer Tasks.png 点击Analyzer Tasks右边的绿色运行箭头,Android Studio会自动的根据此hprof文件分析有哪些类是有内存泄漏的,如下图所示: 下面分析一下MainActivity的泄露情况 MainActivity发生内存泄露.png 在这个界面中可以直接把内存泄露可能的类找出来。 一个Activity应该只有一个实例,但是从A区域来看 total count的值为2,heap count的值也为2,说明有一个是多余的。 在B区域中可以看见两个MainActivity的实例,点击一个看他的引用树情况 在C区域中可以看到MainActivity的实例Context被UserManger的 instance引用了,引用深度为1. 在Analyzer Tasks 区域中,直接告诉你Leaked Activities,MainActivity包含其中 多方面的证据表明MainActivity发生了内存泄露 解决方案 public class UserManger { private static UserManger instance; private Context context; private UserManger(Context context) { this.context = context; } public static UserManger getInstance(Context context) { if (instance == null) { if(context!=null){ instance = new UserManger(context.getApplicationContext()); } } return instance; } } 不要用Activity的Context,因为Activity随时可能被回收,我们用Application的Context,Application的Context的生命周期是整个应用,不回收也没有关系。 Memory Monitor获得内存的动态视图,Heap Viewer显示堆内存中存储了什么,可惜Heap Viewer不能显示你的数据具体分配在代码的何处,如果还不过瘾,想知道具体是哪些代码使用了内存,还有一个功能是Allocation Tracker,用来内存分配追踪。在内存图中点击途中标红的部分,启动追踪,再次点击就是停止追踪,随后自动生成一个alloc结尾的文件,这个文件就记录了这次追踪到的所有数据,然后会在右上角打开一个数据面板Allocation Tracker启动追踪 Allocation Tracker启动追踪.png , Allocation Tracker查看方式 Allocation Tracker查看方式 有两种查看方式,默认是Group by Method方式 Group by Method:用方法来分类我们的内存分配 Group by Allocator:用内存分配器来分类我们的内存分配 从上图可以看出,首先以线程对象分类,Size是内存大小,Count是分配了多少次内存,点击一下线程就会查看每个线程里所有分配内存的方法 Group by Method方式 每个线程里所有分配内存的方法.png OK,-Memory Monitor Group by Allocator方式 EY%HY_B74%BUE22C6$G~CTP.png 右键可以直接跳到源码 - 扇形统计图 AQFHT$@7TYP0S_1`DU@%S%6.png 点击统计图按钮,会生成上图,扇形统计图是以圆心为起点,最外层是其内存实际分配的对象,每一个同心圆可能被分割成多个部分,代表了其不同的子孙,每一个同心圆代表他的一个后代,每个分割的部分代表了某一带人有多人,你双击某个同心圆中某个分割的部分,会变成以你点击的那一代为圆心再向外展开。 Memory Monitor可以发现的问题 Memory Monitor工具为监控工具,是一种发现型或者说监控性质的工具,比如医生的四大技能[望闻问切],[望]是第一步。这里的Memory Monitor就是一种[望]的工具,目前我主要用它来看下面几个内存问题: 1.发现内存抖动的场景 2.发现大内存对象分配的场景 3.发现内存不断增长的场景 4.确定卡顿问题是否因为执行了GC操作 案例分析 上面的第一段标记显示内存突然增加了7M,我们也能看的很清楚,所以这个点我们要去定位了一下问题在哪里,是Bitmap还是什么原因造成的,第二段标记是内存抖动,很明显在很短的时间了发生了多次的内存分配和释放。而且在发生内存抖动的时候,也能感觉到App的卡顿,可以看出来是由于执行了GC操作造成的。 内存的不断增加通过Memory monitor很容易看出来,蓝色的曲线是一路高歌猛进的,一看便知。 本文转自 一点点征服 博客园博客,原文链接:http://www.cnblogs.com/ldq2016/p/8472261.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

Android内存优化9 内存检测工具3 MAT比Menmery Monitor更强大

在Android性能优化第(一)篇---基本概念中讲了JAVA的四大引用,讲了一下GCRoot,第二篇Memory Monitor检测内存泄露仅仅说了Menmery Monitor的使用,这篇博客谈一下MAT来寻找内存泄露,相对来说,Memory Monitor没有MAT强大,但是在开始介绍MAT之前,上两篇没有说清楚的问题先说一下。 GC回收对可回收对象的判定 什么样的对象是可以被回收的? 当然是GC发现通过任何referencechain(引用链)无法访问某个对象的时候,该对象即被回收。名词GC Roots正是分析这一过程的起点,例如JVM自己确保了对象的可到达性(那么JVM就是GC Roots),所以GCRoots就是这样在内存中保持对象可到达性的,一旦不可到达,即被回收。通常GC Roots是一个在current thread(当前线程)的call stack(调用栈)上的对象(例如方法参数和局部变量),或者是线程自身或者是system class loader(系统类加载器)加载的类以及native code(本地代码)保留的活动对象。所以GC Roots是分析对象为何还存活于内存中的利器。 GC Root Tracing算法,对于可回收对象的判定 上面这段话,也写出了检测内存泄露的基本思想:以”GC Roots”的对象作为起始点向下搜索,搜索形成的路径称为引用链,当一个对象到GC Roots没有任何引用链相连(即不可达的),则该对象被判定为可以被回收的对象,反之不能被回收。也写出了内存泄露的原因:对象无用了,但仍然可达(未释放),垃圾回收器无法回收。 好啦,下面开始介绍MAT,MAT工具全称为Memory Analyzer Tool,(MAT下载:http://eclipse.org/mat/downloads.php)是一款详细分析Java堆内存的工具,该工具非常强大,为了使用该工具,我们需要hprof文件。但是该文件不能直接被MAT使用,需要进行一步转化,可以使用hprof-conv命令来转化,但是AndroidStudio可以直接转化。 导出标准的hprof文件 然後用MAT打开我们导出的文件,我导出了两个文件,test1.hprof和test2.hprof,其中test1.hprof是内存未泄露时的快照,test2.hprof是内存已经泄露的快照。我们用MAT的Histogram(直方图)和Dominator Tree (支配树)来分析内存情况。Histogram可以列出内存中每个对象的名字、数量以及大小。Dominator Tree会将所有内存中的对象按大小进行排序,并且我们可以分析对象之间的引用结构。 MAT工具主界面 一、 Histogram(直方图) 可列出每一个类的实例数。支持正则表达式查找,也可以计算出该类所有对象的retained size。默认是通过class(group by class)分类展示的。 直方图.png 这就是test2.hprof的直方图。现在要说两个名词解释。Shallow Heap/Retained Heap Shallow Heap Shallow size就是对象本身占用内存的大小,不包含其引用的对象内存,实际分析中作用不大。在堆上,看起来是一堆原生的byte[], char[], int[],对象本身的内存都很小。所以我们可以看到以Shallow Heap进行排序的Histogram图中,排在第一位第二位的是byte,char Retained Heap Retained size是该对象自己的shallow size,加上从该对象能直接或间接访问到对象的shallow size之和。换句话说,retained size是该对象被GC之后所能回收到内存的总和。RetainedHeap可以更精确的反映一个对象实际占用的大小(因为如果该对象释放,retained heap都可以被释放)。 Histogram中是可以显示对象的数量的,那么比如说我们现在怀疑MainActivity中有可能存在内存泄漏,就可以在第一行的正则表达式框中搜索“MainActivity”,如下所示: 可以看到MainActivity的数量是2,这不正常,解决这个,就需要查看MainActivity被谁引用了,不能被释放。我们右键选择exclude all phantom/weak/soft etc.references, 意思是查看排除虚引用/弱引用/软引用等的引用链 (这些引用最终都能够被GC干掉,所以排除) 还有其他菜单供选择 List objects with (以Dominator Tree的方式查看) incoming references 引用到该对象的对象 outcoming references 被该对象引用的对象 Show objects by class (以class的方式查看) incoming references 引用到该对象的对象 outcoming references 被该对象引用的对象 当你按上面操作之后,凶手就出现了,原来是UserManger的实例。 还有可以通过包名来查看Histogram。 还有更强大的,通过OQL语句查询,有点像写SQL语句。 是不是分分钟查出MainActivity有两个对象。哈哈! 比如:查找size=0并且未使用过的ArrayList select * from java.util.ArrayList where size=0 and modCount=0 这个地方可以多研究研究。 二、Dominator Tree(支配树) Dominator Tree是对象之间dominator关系树。如果从GC Root到达Y的的所有path都经过X,那么我们称X dominates Y,或者X是Y的Dominator Dominator Tree由系统中复杂的对象图计算而来。从MAT的dominator tree中可以看到占用内存最大的对象以及每个对象的dominator。 我们也可以右键选择Immediate Dominator”来查看某个对象的dominator。它可以将所有对象按照Heap大小排序显示, 这样大内存对象就是排在前几名的,我们可以搜索大内存对象通向GC Roots的路径,因为内存占用越高的对象越值得怀疑,使用方法跟Histogram(直方图)差不多,在这里我就不做过多的介绍了。 三、内存快照对比 我们可以将test1.hprof的直方图与test2.hprof的直方图对比来看,其中Object#0是test1.hprof的,Object#1是test2.hprof的,通过比较看哪一些对象的大小相差过大。 内存快照对比 其他资料: 官方的帮助文档http://wiki.eclipse.org/index.php/MemoryAnalyzer 使用 Eclipse Memory Analyzer 进行堆转储文件分析http://www.vogella.de/articles/EclipseMemoryAnalyser/article.html MAT使用教程http://www.vogella.de/articles/EclipseMemoryAnalyser/article.html 本文转自 一点点征服 博客园博客,原文链接:http://www.cnblogs.com/ldq2016/p/8472753.html,如需转载请自行联系原作者

优秀的个人博客,低调大师

Vesta v1.0.7 云原生安全检测工具发布:增加云原生后门检测

Vesta 是一款高效、方便的容器扫描以及 Docker、Kubernetes 基线安全检查工具。 致力检查因 Docker 或 Kubernetes 错误配置以及镜像软件安全问题而导致的各种潜在危害的发生。 Vesta v1.0.7 更新内容如下: 新功能 增加漏洞源OSCS作为Python和Node投毒包检测 增加部分 Docker 安全配置检测规则 包括增加windows的危险挂载路径检测,Docker 镜像layer的危险命令检测 增加node安全权限检测 对于攻击中通过尝试将Pod所在的node节点从底权限转移到master节点转移从而或者更高的操作权限,vesta通过检测nodeSelector等关键参数并告警。最大化使得安全人员能够观测到不安全的行为 增加PodScurityPolicy和k8s版本的检测 增加云原生后门的检测 主要检查Daemonset上rootkit,包括检测ConfigMap,Secret等是否包含恶意命令或者为可执行文件。同时为最大程度保证误报的数量,采用检测DaemonSet启动时间以及重启次数做对比,详情可以见https://mp.weixin.qq.com/s/jxDPMYXQMMHcEf2Gf5o62Q 改进 增加CAP以及Podannotation的检测规则 修改Job以及CronJob的检测方法 修复 修复下载漏洞库源时因时间格式的错误导致的重复下载 修复内核版本的检测准确性

优秀的个人博客,低调大师

Vesta v1.04 云原生安全检测工具发布:增加供应链投毒检测

Vesta 是一款实用、方便的镜像扫描以及 Docker、Kubernetes 基线安全检查工具。 致力检查因 Docker 或 Kubernetes 错误配置而导致的各种潜在安全问题的发生。 Vesta v1.0.4 更新内容如下: 新功能 增加sidecar中Env以及EnvFrom中变量检查,并且定位到具体的ConfigMap或Secret 增加Pod annotation检测 增加供应链投毒检测 改进 更改了的rpm检测的方法 更改了containerd内核检测方法 upgrade命令更换为update vesta 收集了网上用量最多的包名字以及目前已知的恶意包名字,与容器中已安装的包进行相似度对比,相似度大于80%即判断为可疑的投毒包(目前仅支持python的检测,后期将加入其他语言的检测以及镜像投毒检测)

优秀的个人博客,低调大师

Vesta v1.0.3 云原生安全检测工具 发布:增加大量RBAC检测规则

Vesta 是一款实用、方便的镜像扫描以及 Docker、Kubernetes 基线安全检查工具。 致力检查因 Docker 或 Kubernetes 错误配置而导致的各种潜在安全问题的发生。 Vesta v1.0.3 更新内容如下: 新功能 镜像检查增加对Java,PHP,Rust依赖的版本检查支持 增加istio的检查,包括istio版本检查,以及istio header请求过度敏感信息检查,参考issue 增加Docker history命令行检查,检查是否存在echo 弱密码的命令出现 改进 npm检查方法改进,采用全局搜索package.json文件进行分析 运行的容器检查将挂载的路径加入到检查内容中 改进镜像Layer的分析方法 修改RBAC的检测规则 更加详细的结果打印 在RBAC检测中,我们注意到未知User的高危权限应该被打印出来以供开发者自查。同时RBAC的风险等级被重新化为high,medium,low,warning四个等级,对高风险resources,例如pods,deployments等结合对应的操作权限进行重点检查,未知resources将不再化为高风险范围。增加Group的风险检查,包括system:unauthenticated,system:serviceaccounts: 等类名的检测,并且将rolebinding检测的结果结合/var/run/secrets/kubernetes.io/serviceaccount的挂载情况进行综合评估。用例如下 Pods: +----+--------------------------------+--------------------------------+--------------------------------+-----------------------+----------+--------------------------------+ | ID | POD DETAIL | PARAM | VALUE | TYPE | SEVERITY | DESCRIPTION | +----+--------------------------------+--------------------------------+--------------------------------+-----------------------+----------+--------------------------------+ | 1 | Name: vulntest | Namespace: | sidecar name: vulntest | | true | Pod | critical | There has a potential | | | default | Status: Running | | Privileged | | | | container escape in privileged | | | Node Name: docker-desktop | | | | | module. | + + +--------------------------------+--------------------------------+-----------------------+----------+--------------------------------+ | | | sidecar name: vulntest | | memory, cpu, ephemeral-storage | Pod | low | None of resources is be | | | | Resource | | | | limited. | | | | | | | | | +----+--------------------------------+--------------------------------+--------------------------------+-----------------------+----------+--------------------------------+ | 2 | Name: vulntest2 | Namespace: | sidecar name: vulntest2 | | CAP_SYS_ADMIN | capabilities.add | critical | There has a potential | | | default | Status: Running | | capabilities | | | | container escape in privileged | | | Node Name: docker-desktop | | | | | module. | + + +--------------------------------+--------------------------------+-----------------------+----------+--------------------------------+ | | | sidecar name: vulntest2 | | true | kube-api-access-lcvh8 | critical | Mount service account | | | | automountServiceAccountToken | | | | and key permission are | | | | | | | | given, which will cause a | | | | | | | | potential container escape. | | | | | | | | Reference clsuterRolebind: | | | | | | | | vuln-clusterrolebinding | | | | | | | | | roleBinding: vuln-rolebinding | + + +--------------------------------+--------------------------------+-----------------------+----------+--------------------------------+ | | | sidecar name: vulntest2 | | cpu | Pod | low | CPU usage is not limited. | | | | Resource | | | | | | | | | | | | | +----+--------------------------------+--------------------------------+--------------------------------+-----------------------+----------+--------------------------------+ Configures: +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ | ID | TYPEL | PARAM | VALUE | SEVERITY | DESCRIPTION | +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ | 1 | K8s version less than v1.24 | kernel version | 5.10.104-linuxkit | critical | Kernel version is suffering | | | | | | | the CVE-2022-0185 with | | | | | | | CAP_SYS_ADMIN vulnerablility, | | | | | | | has a potential container | | | | | | | escape. | +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ | 2 | ConfigMap | ConfigMap Name: vulnconfig | db.string:mysql+pymysql://dbapp:Password123@db:3306/db | high | ConfigMap has found weak | | | | Namespace: default | | | password: 'Password123'. | +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ | 3 | Secret | Secret Name: vulnsecret-auth | password:Password123 | high | Secret has found weak | | | | Namespace: default | | | password: 'Password123'. | +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ | 4 | ClusterRoleBinding | binding name: | verbs: get, watch, list, | high | Key permissions with key | | | | vuln-clusterrolebinding | | create, update | resources: | | resources given to the | | | | rolename: vuln-clusterrole | | pods, services | | default service account, which | | | | kind: ClusterRole | subject | | | will cause a potential data | | | | kind: Group | subject name: | | | leakage. | | | | system:serviceaccounts:vuln | | | | | | | | namespace: vuln | | | | +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ | 5 | RoleBinding | binding name: vuln-rolebinding | verbs: get, watch, list, | high | Key permissions with key | | | | | rolename: vuln-role | role | create, update | resources: | | resources given to the | | | | kind: Role | subject kind: | pods, services | | default service account, which | | | | ServiceAccount | subject name: | | | will cause a potential data | | | | default | namespace: default | | | leakage. | +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ | 6 | ClusterRoleBinding | binding name: | verbs: get, watch, list, | warning | Key permission are given | | | | vuln-clusterrolebinding2 | | create, update | resources: | | to unknown user 'testUser', | | | | rolename: vuln-clusterrole | | pods, services | | printing it for checking. | | | | subject kind: User | subject | | | | | | | name: testUser | namespace: | | | | | | | all | | | | +----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+ 修复 修复版本对比中由于非数字字符串带来的对比失败

优秀的个人博客,低调大师

开发者的硬核福利:专为开发者而生的免费开源安全检测工具

近日,棱镜七彩推出开源安全与合规管理平台FossEye个人版,免费为开发者提供开源安全检测服务。 PS:开源项目开发者有特殊福利哦! 【关于FossEye】 随着计算机技术的发展,开源软件的使用率正在平衡快速增长,在软件开发过程中使用开源软件时,不应仅仅关注开源软件的功能,还应把安全作为重要因素纳入考量。FossEye平台专注于通过软件生命周期开源软件安全管理平台识别并规避相关开源风险,提供全面的解决方案,帮助开发者实现开源的安全性,确保其产品和服务的安全,建立一个健康的开源软件生态系统。 FossEye平台主要针对软件供应链中的依赖组件的安全与合规进行治理,个人版支持对开源软件和依赖组件进行持续、自动化的识别、安全分析、智能修复建议、许可证检测、每日漏洞更新持续跟踪、通知机制等,企业版在个人版的基础上增加了支持库资产管理,私有仓库、本地仓库集成,并与第三方开发工具无缝集成,实现自动化的安全分析、策略执行、持续集成,形成多维度报告与可视化工作台,同时支持docker扫描、静态扫描,提供api使用权限。 Gitee 现已接入棱镜七彩FossEye的许可证合规分析服务。FossEye 依据棱镜七彩深入研究的许可证知识库,能够帮助用户了解软件中的开源许可证及相关要求,及时发现许可证风险。

优秀的个人博客,低调大师

Android内存优化8 内存检测工具2 LeakCanary——直白的展现Android中的内存泄露

之前碰到的OOM问题,终于很直白的呈现在我的眼前:我尝试了MAT,但是发现不怎么会用。直到今天终于发现了这个新工具: 当我们的App中存在内存泄露时会在通知栏弹出通知: 当点击该通知时,会跳转到具体的页面,展示出Leak的引用路径,如下图所示: LeakCanary 可以用更加直白的方式将内存泄露展现在我们的面前。 以下是我找到的学习资料,写的非常棒: 1、LeakCanary: 让内存泄露无所遁形 2、LeakCanary 中文使用说明 AndroidStudio(官方)上使用LeakCanary 请移步:https://github.com/square/leakcanary Eclipse上使用LeakCanary 请移步我的:https://github.com/SOFTPOWER1991/LeakcanarySample-Eclipse Androidstudio(自己弄的)上使用LeakCanary也可以看这个: leakcanarySample_androidStudio 工程包括: LeakCanary库代码 LeakCanaryDemo示例代码 使用步骤: 将LeakCanary import 入自己的工程 添加依赖: compile project(':leakcanary') 在Application中进行配置 public class ExampleApplication extends Application { ...... //在自己的Application中添加如下代码 public static RefWatcher getRefWatcher(Context context) { ExampleApplication application = (ExampleApplication) context .getApplicationContext(); return application.refWatcher; } //在自己的Application中添加如下代码 private RefWatcher refWatcher; @Override public void onCreate() { super.onCreate(); ...... //在自己的Application中添加如下代码 refWatcher = LeakCanary.install(this); ...... } ..... } 在Activity中进行配置 public class MainActivity extends AppCompatActivity { ...... @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); //在自己的应用初始Activity中加入如下两行代码 RefWatcher refWatcher = ExampleApplication.getRefWatcher(this); refWatcher.watch(this); textView = (TextView) findViewById(R.id.tv); textView.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { startAsyncTask(); } }); } private void async() { startAsyncTask(); } private void startAsyncTask() { // This async task is an anonymous class and therefore has a hidden reference to the outer // class MainActivity. If the activity gets destroyed before the task finishes (e.g. rotation), // the activity instance will leak. new AsyncTask<Void, Void, Void>() { @Override protected Void doInBackground(Void... params) { // Do some slow work in background SystemClock.sleep(20000); return null; } }.execute(); } } 在AndroidMainfest.xml 中进行配置,添加如下代码 <service android:name="com.squareup.leakcanary.internal.HeapAnalyzerService" android:enabled="false" android:process=":leakcanary" /> <service android:name="com.squareup.leakcanary.DisplayLeakService" android:enabled="false" /> <activity android:name="com.squareup.leakcanary.internal.DisplayLeakActivity" android:enabled="false" android:icon="@drawable/__leak_canary_icon" android:label="@string/__leak_canary_display_activity_label" android:taskAffinity="com.squareup.leakcanary" android:theme="@style/__LeakCanary.Base" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> 5、测试结果 a、Toast显示(大概10秒左右显示) b、通知显示 c、桌面自动添加的图表 d、内存泄露列表 e、内存泄露详细 LogCat可以看到日志日下(hprof文件可以用MAT打开进行分析): [html] view plain copy 01-0411:49:41.81512967-13004/com.micky.leakcanarysamplesI/dalvikvm:hprof:dumpingheapstringsto"/storage/emulated/0/Download/leakcanary/suspected_leak_heapdump.hprof". 01-0411:49:42.02012967-13004/com.micky.leakcanarysamplesI/dalvikvm:hprof:heapdumpcompleted(28850KB) 查看自动生成的AndroidManifest文件,LeakCanarySamples/app/build/intermediates/manifests/full/debug/AndroidManifest.xml [html] view plain copy <?xmlversion="1.0"encoding="utf-8"?> <manifestxmlns:android="http://schemas.android.com/apk/res/android" package="com.micky.leakcanarysamples" android:versionCode="1" android:versionName="1.0"> <uses-sdk android:minSdkVersion="10" android:targetSdkVersion="23"/> <!--Tostoretheheapdumpsandleakanalysisresults.--> <uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/> <android:uses-permissionandroid:name="android.permission.READ_EXTERNAL_STORAGE"/> <application android:name="com.micky.leakcanarysamples.BaseApplication" android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:supportsRtl="true" android:theme="@style/AppTheme"> <activity android:name="com.micky.leakcanarysamples.MainActivity" android:label="@string/app_name" android:theme="@style/AppTheme.NoActionBar"> <intent-filter> <actionandroid:name="android.intent.action.MAIN"/> <categoryandroid:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> <activityandroid:name="com.micky.leakcanarysamples.TestActivity"/> <service android:name="com.squareup.leakcanary.internal.HeapAnalyzerService" android:enabled="false" android:process=":leakcanary"/> <service android:name="com.squareup.leakcanary.DisplayLeakService" android:enabled="false"/> <activity android:name="com.squareup.leakcanary.internal.DisplayLeakActivity" android:enabled="false" android:icon="@drawable/__leak_canary_icon" android:label="@string/__leak_canary_display_activity_label" android:taskAffinity="com.squareup.leakcanary" android:theme="@style/__LeakCanary.Base"> <intent-filter> <actionandroid:name="android.intent.action.MAIN"/> <categoryandroid:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity> </application> </manifest> 如上所示LeakCanary给我们自动添加了两个Service和一个Activity,并添加了对SD卡的读写权限 It 's so simple. 注: 1、如果在Release模式下请使用RefWatcher.DISABLED 2、在Activity或Fragment 的 Destroy方法中添加检测(很好理解,就是判断一个Activity或Fragment想要被销毁的时候,是否还有其他对象持有其引用导致Activity或Fragment不能被回收,从而导致内存泄露) 本文转自 一点点征服 博客园博客,原文链接: http://www.cnblogs.com/ldq2016/p/8472721.html ,如需转载请自行联系原作者

优秀的个人博客,低调大师

Vesta v1.0.5 云原生安全检测工具发布:增加大量 Python 模块的安全检测

Vesta 是一款高效、方便的容器扫描以及 Docker、Kubernetes 基线安全检查工具。 致力检查因 Docker 或 Kubernetes 错误配置以及镜像软件安全问题而导致的各种潜在危害的发生。 Vesta v1.0.5 更新内容如下: 新功能 增加Python poetry包管理安装包检测以及Python venv虚拟环境包检测 增加部分Docker安全配置检测规则 改进 将下载漏洞库的最低年份从2002年提高到2010年,检测初始化下载所消耗的时间 Docker History命令检查增加对${ENV}格式的内容识别 优化镜像扫描输出格式,对不同语言依赖包进行单独显示 优化Java依赖的识别,并且着重检查log4j漏洞 增加PyPi恶意包的检测 PyPi恶意包检测除去对目前主流包的名字进行相似度检测之外,增加对文件内容的检测。同时考虑的镜像扫描的速度以及对大量投毒包的分析,目前只对所有模块的setup.py和文件夹的__init__.py文件进行内容检测,检测外链URL路径,检测制定的命令执行函数并且检测命令执行内容,最大包保证每一个Python包的安全性

优秀的个人博客,低调大师

腾讯云 TDSQL 数据库核心技术理论取得进展,同时发布数据异常检测工具

近日,腾讯云和中国人民大学在数据库基础研究上有了进展,聚焦在“数据异常”领域,这是数据库可串行化理论体系中的重要概念。 数据异常是打开并发访问控制技术大门的金钥匙。在数据库行业中,以往只发现了10多种数据异常现象,但腾讯云TDSQL数据库团队对数据异常做了体系化研究,证明了数据异常是无穷多的。同时,开发出一款小程序(已经开源),可以检测识别出任何种类的数据异常。目前,该基础研究已经申请专利、并正在申报行业学术论文。 过去在数据库基础研究中,文献讨论的都是通过一个一个数据异常案例(case by case)来进行讨论、提出有限个数的异常,缺乏全局观,并不利于认识数据异常,也不利于掌握并发访问控制算法。腾讯云数据库的科学家们,将数据异常做了定义:并发事务的一个History中,如存在一个依据偏序对构成的有向环,则称为数据异常。在定义了数据异常后,进一步据此简明易懂地定义了事务的一致性:不存在数据异常则称为数据符合一致性。 该基础研究的核心意义在于,可探究到数据异常的本质和内在规律,并揭示出隔离级别和并发算法的本质,使得基于该项基础技术工作可进一步系统地研究各种并发访问控制算法、改进并发算法。 这对于数据库领域,属于基础地开创性工作。与传统对的可串行化理论相对,该新方法具有诸多优势,如下图: (腾讯云数据库团队TDSQL数据异常体系化研究方向及新理论应用) 作为三大基础软件之一,数据库的安全可控和技术创新关乎国计民生,在国家大力发展新基建以及倡导走“更高水平的自力更生之路”背景下,加快实现新兴国产数据库的安全可控。 近年来,腾讯云数据库的研究主要聚焦在数据库核心基础理论层面的研究与实践,例如分布式一致性与事务性一致性融合的体系化的研究;再如事务性数据异常的体系化研究,重新对事务一致性做了定义等。 2021年3月,国务院新闻办就加快建设创新型国家全面支撑新发展格局举行发布会,国家正在系统推进基础研究和关键核心技术攻关,科技创新能力实现“新跃升”。以腾讯为代表的中国互联网公司正在不断加强基础科学领域的投入。全球最权威的文献摘要和引文数据库Scopus的数据显示,在计算机科学领域,腾讯以1639篇学术文献量位居全球前列。

优秀的个人博客,低调大师

技术日报|superpowers 突破 15.7 万星重夺榜首,Google AI 文件检测工具magika强势入榜

🌟 TrendForge 每日精选 - 发现最具潜力的开源项目 📊 今日共收录 15 个热门项目 🌐 智能中文翻译版 - 项目描述已自动翻译,便于理解 🏆 今日最热项目 Top 10 🥇 obra/superpowers 项目简介: Claude Code 超级能力:核心技能库 今日新增: 1713 * 总星数: 157744 * 语言: Shell https://github.com/obra/superpowers 🥈 google/magika 项目简介: 快速准确的AI驱动文件内容类型检测。 今日新增: 956 * 总星数: 15448 * 语言: Python 项目截图: google/magika https://github.com/google/magika 🥉 Lordog/dive-into-llms 项目简介: 《动手学大模型》系列编程实践教程 今日新增: 944 * 总星数: 31508 * 语言: Jupyter Notebook https://github.com/Lordog/dive-into-llms 4. lsdefine/GenericAgent 项目简介: 自进化智能体:从3300行种子代码生长技能树,以降低6倍的令牌消耗实现完整系统控制。 今日新增: 845 * 总星数: 3604 * 语言: Python 项目截图: lsdefine/GenericAgent https://github.com/lsdefine/GenericAgent 5. BasedHardware/omi 项目简介: AI可穿戴设备 戴上即说即转录 今日新增: 824 * 总星数: 9815 * 语言: Dart 项目截图: BasedHardware/omi https://github.com/BasedHardware/omi 6. jamiepine/voicebox 项目简介: 开源语音合成工作室 今日新增: 797 * 总星数: 19837 * 语言: TypeScript 项目截图: jamiepine/voicebox https://github.com/jamiepine/voicebox 7. EvoMap/evolver 项目简介: 基于GEP驱动的AI智能体自进化引擎。基因组进化协议。* evomap.ai 今日新增: 737 * 总星数: 4222 * 语言: JavaScript https://github.com/EvoMap/evolver 8. openai/openai-agents-python 项目简介: 一个轻量级、强大的多智能体工作流框架 今日新增: 625 * 总星数: 21801 * 语言: Python https://github.com/openai/openai-agents-python 9. SimoneAvogadro/android-reverse-engineering-skill 项目简介: 支持Android应用逆向工程的Claude Code技能 今日新增: 538 * 总星数: 2732 * 语言: Shell https://github.com/SimoneAvogadro/android-reverse-engineering-skill 10. Donchitos/Claude-Code-Game-Studios 项目简介: 将Claude代码转化为完整的游戏开发工作室——包含48个AI智能体、36项工作流技能,以及模拟真实工作室层级的完整协作... 今日新增: 311 * 总星数: 11767 * 语言: Shell https://github.com/Donchitos/Claude-Code-Game-Studios 📈 今日趋势分析 最活跃语言: Python(5个)、TypeScript(4个)、Shell(3个) 今日总获星: 9,294 颗星 平均获星: 620 颗星/项目 今日之星: obra/superpowers (1713) 📊 数据总览 指标 数值 收录项目 15 个 编程语言 0 种 今日新增 9,294 颗星 报告日期 2026年04月17日 统计周期 日报 TrendForge 致力于追踪全球开源项目动态,每日为开发者精选最具价值的 GitHub 项目。 数据来源: https://trendforge.devlive.top/ 数据说明: 基于 GitHub 官方 API 数据统计,每日更新 翻译声明: 项目描述采用 AI 智能翻译,如有疏漏请以原文为准 报告生成于: 2026年04月18日 #GitHub #开源项目 #技术趋势 #程序员 #软件开发

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册