首页 / 资讯中心 / 文章详情

AiSOC 文件与 URL 分析 Provider 详解:上传即披露的沙箱接入、配置与审计实践

AiSOC 文件与 URL 分析 Provider 详解:上传即披露的沙箱接入、配置与审计实践 ★ FEATURED ARTICLE
人工智能AI Agent网络安全后端前端【免费下载链接】AiSOCOpen-source AI Security Operations Center: alert fusion, LLM-agent triage, MITRE ATTCK investigation, and a replayable decision ledger for every agent step. Self-hostable, runs with no API keys, MIT licensed. Ships an MCP server for Claude, Cursor and Continue.项目地址https://gitcode.com/GitHub_Trending/ai/AiSOC点击查看免费下载AiSOC 通过一套统一的 provider 契约对接恶意软件沙箱与文件信誉服务让控制台、富化链路和调查 Agent 在不同后端之间看到同一套词汇verdict、score、signatures、IOC 与 ATTCK 映射。本文以运维文档 sandbox-providers.md 为主线结合 services/api/app/services/sandbox 下的真实实现、数据库迁移与 CI gate讲清三件事为什么要先查哈希再上传、三个 provider 各自怎么配、以及失败和未知为什么绝不能被渲染成干净。一、一个接口三套后端AiSOC 目前随仓库提供三个 providerProvider运行位置是否支持上传状态capev2你自己的网络是开源参考实现。按 CAPEv2 REST API 文档编写未在真实实例上验证malwareanalyzer托管、第三方是默认公开发布商业适配器。哈希查询与报告映射已在线上服务验证鉴权未验证mock进程内无实际效果不做任何分析。存在的意义是让没配沙箱的部署也能把整条链路跑通这三个名字不是硬编码在业务逻辑里的。provider 的能力由 types.py 中的ProviderCapabilities声明注册表由 registry.py 的build_registry()按环境变量组装providers [] cape_url (os.getenv(AISOC_CAPEV2_URL) or ).strip() if cape_url: providers.append(CapeV2Provider(cape_url, api_tokenos.getenv(AISOC_CAPEV2_TOKEN))) if _enabled(AISOC_MALWAREANALYZER_ENABLED): providers.append(MalwareAnalyzerProvider()) providers.append(MockSandboxProvider()) # 永远存在_enabled()的判定集合是{1, true, yes, on}默认关闭。源码注释给出的理由值得抄进任何安全产品设计里一个托管分析 provider 仅因为 base URL 有默认值就自己打开就是一次没人要求的出站调用。SandboxRegistry.default()的选择顺序也有讲究先剔除 mock再在剩下的可用 provider 中优先选localTrue的那个。所以一台配了 CAPEv2 的机器默认走 CAPEv2而不是 mock只有什么都没配时mock 才是默认值。二、最要紧的规则上传一个文件就是一次披露SHA-256 查询告诉 provider 的只是一个 32 字节摘要上传文件告诉它的是这个文件本身。这是两种性质不同的行为AiSOC 也区别对待。哈希查询永远先跑。如果 provider 已经分析过该文件直接复用已有报告什么都不上传。这是最常见的情况也不产生任何披露成本。上传默认关闭。必须由持有settings:write权限的人按租户 × 按 provider双重开启并记录是谁做的决定、当时看到的是哪一版披露文本。之所以按 provider 而不是按租户是因为同意把样本送到自己机架里的沙箱并不等于同意送到托管服务。气隙模式只允许本地 provider。AISOC_AIRGAPPED打开时托管 provider 仍然出现在设置列表里但被标记为排除并附上原因而不是悄悄消失。registry.py 把这一点写成了两个方法names()返回全部已配置的 providerusable_names()只返回可用的is_usable()的判定就是provider.local or not airgapped。每个决定都留痕包括拒绝。aisoc_sandbox_submissions每个 artefact 一行带 outcome、原因以及一个仅在字节真的离开部署时为真的uploaded布尔列。这一列就是有没有客户文件去了第三方这个问题唯一可靠的答案来源。2.1 同意文本是版本化的不是一句布尔policy.py 用CONSENT_TEXT_VERSION 2026-09-26.1把文案版本固化下来并随同意记录一起落库。consent_text_for()会按 provider 能力生成三种不同措辞submissions_are_public_by_defaultTrue明确写上传的文件与报告对互联网上任何人可读且无法撤回非本地 provider写文件离开你的基础设施并按该厂商条款留存本地 provider写文件不离开你的基础设施但仍会写入该系统自己的存储。三种措辞共用最后一句AiSOC 总是先查 SHA-256只有 provider 没见过时才上传。每次上传和每次拒绝都记在本租户名下。源码注释解释了为什么本地 provider 也不能默认开启同意迁移 064_sandbox_upload_policy.sql 的注释同样强调了这点本地沙箱仍然把文件写进一个有自己留存策略的系统。2.2 MalwareAnalyzer 的同意文案为什么写public启用向malwareanalyzer上传时运维看到的是这段文字Enabling uploads lets AiSOC send files from this tenant to malwareanalyzer for analysis. A file may contain customer data, credentials, personal data or intellectual property. AiSOC cannot inspect a file to decide whether it does. malwareanalyzer publishes submitted samples by default: an uploaded file and its report become readable by anyone on the internet, not only by the vendor. Treat every upload as a public disclosure that cannot be recalled. AiSOC always looks a files SHA-256 up first and only uploads when the provider has not seen it. Every upload and every refusal is recorded against this tenant.public这个词不是修辞。适配器记录的事实是从GET /v1/reports/sha256取回的报告里带着visibility: public与tlp: clear。TLP:CLEAR 是 Traffic Light Protocol 中无限制的级别所以这不是厂商内部的默认值——样本对任何人都可读。这一点在测试夹具里留下了证据。services/api/tests/fixtures/sandbox/malwareanalyzer_report_eicar.json 是对 EICAR 测试文件按其哈希做 GET 得到的真实响应fixtures README 明确说明构建该适配器的过程中没有上传任何文件其中同时包含visibility: public、tlp: clear与fileType: unknown。服务自己的 Web 客户端在上传时确实会发visibility字段并提供private选项但在未登录时会钉死public并禁用该控件。因此private看起来需要已认证账号。AiSOC 的策略是请求你配置的 visibility但不对它是否被遵守做任何假设——只有当运维显式设置MALWAREANALYZER_PRIVATE_SUBMISSIONS_CONFIRMED1这是他们确认过私有上传对自己的账号有效的声明时submissions_are_public_by_default才会在同时配置了 API key 的前提下变为Falsesubmissions_are_public_by_defaultnot (bool(self._key) and self._private_confirmed),源码的取舍写得很明白让一个 API key 就改写这句措辞等于用未验证的假设重写别人在披露客户文件前同意的那句话。2.3 四道拒绝顺序本身就是安全属性evaluate_upload()是一个纯函数policy.py按固定顺序返回UploadRefusal之一气隙先行AIRGAPPEDairgapped and not capabilities.local时直接拒绝。没有任何租户同意能覆盖它且结论与租户无关。provider 是否能收PROVIDER_CANNOT_UPLOAD只支持哈希查询的 provider 是不能收与策略不允许是不同含义混为一谈会让运维去找一个根本不存在的同意开关。哈希优先ALREADY_KNOWN这一分支带satisfied_by_hash_lookupTrue意思不是被禁止而是不需要。它是常见情况。租户同意TENANT_NOT_CONSENTED默认关闭键是(tenant, provider)。只有四道全部通过才会构造allowedTrue。UploadDecision的注释特意点明allowed永远不会因为忘了设而为真。services/api/tests/test_sandbox_upload_policy.py与 scripts/check_sandbox_upload_policy.py 双向守护这些性质正向遍历(local/hosted/lookup_only) × airgapped × consented × hash_known的全部组合并断言允许/拒绝结果反向读取源码 AST检查是否有异常处理器在构造SandboxReport、是否有同意类标志默认为True、analyse_file里lookup_hash是否排在evaluate_upload之前。三、配置默认什么都没有开。先看 CAPEv2。3.1 CAPEv2推荐也是气隙场景唯一选项AISOC_CAPEV2_URLhttp://cape.internal:8000 AISOC_CAPEV2_TOKEN # 可选开放实例上请整行省略如果实例不要求 token就不要设置它。AiSOC 在无 token 时完全不发送Authorization头而不是发一个空头——空头会把一个开放实例变成 401见 capev2.py。CAPEv2 的映射值得留意因为它是接口拥有词汇的最好例证CAPE 发布 0–10 的malscore并且完全不发布 verdict 字符串。所以适配器把malscore × 10归一化到 0–100并自行推导verdictmalscorescore推导出的 verdict≥ 7.070–100malicious≥ 3.0 且 7.030–69suspicious 0 且 3.01–29unknown 00benign缺失 / 非数值unavailableunavailable这些阈值是适配器自己的判断源码明确要求它们被写在适配器、API 响应和运维文档里而不能包装成CAPE 的看法。另一处细节CAPE 对哈希查询的未命中返回的是200加error: true所以只看状态码无法区分命中与未命中适配器先看body.get(error)再从data[0].id取 task id 并转去poll()。3.2 MalwareAnalyzerAISOC_MALWAREANALYZER_ENABLED1 MALWAREANALYZER_BASE_URLhttps://malwareanalyzer.com MALWAREANALYZER_API_KEY # 可选见下 MALWAREANALYZER_API_KEY_HEADERAuthorization MALWAREANALYZER_API_KEY_PREFIXBearer MALWAREANALYZER_PRIVATE_SUBMISSIONS_CONFIRMED # 只有你自己验证过之后才设置注意鉴权未经验证该服务公开宣称No API key requiredAiSOC 发出的每个调用也确实不需要 key。但存在一个需要认证的面例如GET /v1/vault/samples会返回401且其 Web 客户端发送的是Authorization: Bearer token这也是这里的默认值。问题在于伪造的Bearer与伪造的x-api-key会产生逐字节相同的401CORS 预检又会回显任何被请求的头因此两者都无法为一个新签发的 API key确认方案。没有人用真实 key 确认过。MALWAREANALYZER_API_KEY_HEADER与MALWAREANALYZER_API_KEY_PREFIX存在就是为了让你不改代码也能纠正它设置界面把鉴权显示为未验证而不是打一个这个项目还没挣到的勾。如果你持有真实 key 并确定了方案请开 issue。前缀的默认逻辑同样是独立可变的设计当 header 是Authorization时默认Bearer其他 header 默认空前缀也可以被MALWAREANALYZER_API_KEY_PREFIX覆盖。3.3 部署侧传参的一个真实差异从源码看注册表读取的是AISOC_CAPEV2_URL/AISOC_CAPEV2_TOKENregistry.py而 docker-compose.yml 传给api服务的是AISOC_CAPEV2_BASE_URL/AISOC_CAPEV2_API_TOKEN另加AISOC_AIRGAPPED、MALWAREANALYZER_BASE_URL、MALWAREANALYZER_API_KEY。docs 中的示例用的是AISOC_CAPEV2_URL与代码一致而 CI 测试 test_sandbox_settings_reach_the_api.py 只断言 compose 的api服务块里存在AISOC_CAPEV2_BASE_URL等变量名并不校验名字是否与注册表读取的一致。因此用 Compose 部署时建议先确认实际注入到容器内的变量名——以注册表读取的名字为准或者通过environment:显式映射。这是一个可验证的命名差异不是能力缺失。AISOC_AIRGAPPED必须被传到api服务因为它在 API 内被多个模块读取core/airgap.py、llm_status.py、stix_taxii.py、sandbox registry 等。气隙 overlay infra/compose/docker-compose.airgap.yml 必须把这个变量设到api上否则自认为是气隙部署的只有别的一些服务。四、pending 与查不到如何浮现沙箱天生慢且易失败。有两个状态在所有传递路径上都与干净结果保持区分Pending。已提交但尚无裁决。报告带state: pending或running其 verdict 字段读作unavailable。它永远不会被渲染成 benignAgent 也会被告知分析未完成。Could not check。provider 超时、拒绝鉴权或返回无法解析的内容会产生outcome: could_not_check并附上原因。它永不产生报告。对调查 Agent 来说两者都以available: false抵达并带有明确措辞文件没有被评估过而这本身不构成文件是干净的证据。这个区别正是关键一个把超时读成无检出的模型会给一个没人分析过的文件写下良性结论。未知哈希同理。没有任何 provider 分析过这个文件与某个 provider 分析过并什么也没发现在语义上是两件事而定向恶意软件按设计就对所有公共服务未知。服务层用一个Literal把五种结果压成可分支的一个词service.pyoutcome含义是否附带reportknown存在报告且已附带是pending分析进行中拿handle回来轮询否有receiptnot_seen没人分析过什么都没上传否upload_refused需要上传但策略拒绝否有decisioncould_not_check问不到 provider。不是裁决否注释点明了一个有意的设计五种 outcome 共用一个返回类型这样忘了处理could_not_check的调用方拿到的是reportNone而不是一个可以被吞成干净的异常。poll()的两个映射同样值得记住state is NOT_FOUND→outcomenot_seenstate is FAILED→outcomecould_not_check措辞为provider 分析失败未达成任何裁决。五、unavailable 不是零当 provider 不发布接口里的某个字段时它读作unavailable既不是0也不是[]并附带原因。实现上这是一个单例哨兵UNAVAILABLEtypes.py__bool__返回False所以if report.attack:不会误真但它从不等于[]、0或None。配套的is_available()声明为TypeGuard让类型检查器能在正分支里收窄类型——注释解释这是为了让调用点愿意用这个 helper而不是绕过它。最清晰的例子就在测试夹具里。一个文件类型无法识别、行为阶段根本没跑的 MalwareAnalyzer 报告会带着attackTechniques: []与behavior.analyzed: false一起返回。列表为空的原因是从未选到 guest、行为阶段没执行而不是样本没有展现出任何技术。malwareanalyzer.py 的处理是elif not raw_attack and behavior.get(analyzed) is False: attack UNAVAILABLE detail str(behavior.get(reason) or ).strip() or unspecified reasons[attack] fbehavioural analysis did not run ({detail}), so no techniques could be observed对调用方输出的就是文档里那段 JSON{ attack: unavailable, unavailable_reasons: { attack: behavioural analysis did not run (unidentified_file_type), so no techniques could be observed } }同一个 payload若行为阶段被标记为已执行则会产生一个真正的空列表含义是我们看过了没有发现。SandboxReport.summary()把这一点落到 prompt 与 API 响应上不可用字段渲染成字符串unavailable而不是被删掉因为一个干脆缺失的 key在模型眼里就是一个可以自行推断的字段。signatures截断到 25 条IOC 每个桶截断到 50 条。CAPEv2 侧则是相反方向的诚实CAPE 确实跑了行为阶段因此attacktuple(techniques.values())即使为空元组也是真答案——看过了没有映射到技术。六、Agent 工具lookup_file_hash调查 Agent 只拿到一个工具lookup_file_hash它不能上传。这不是传输层限制而是刻意设计。上传是由运维慎重记录的同意所管辖的披露行为这种后果级别的决定不该藏在一句模型选择输出的文本背后。否则附件名里的一条注入指令就离把附件外泄只差一步。实现位于 services/agents/app/tools/sandbox.py。几处值得运维了解的细节先做格式校验必须匹配^[0-9a-fA-F]{64}$否则返回outcomeinvalid_input不浪费一次网络调用。工具用 agent 服务自己的凭据AISOC_API_SERVICE_TOKEN回退到AISOC_SERVICE_TOKEN调用 API并不传租户作为请求体字段租户由凭据在 API 侧解析出来。源码注释直言一个名为tenant_id的工具参数是这个面上最值得注入的东西。请求超时为 15 秒短到卡住的 provider 无法把工具循环挂住。所有失败路径统一走_could_not_check()措辞固定为这是一次查询失败不是干净结果文件没有被评估过。请勿把它当作该文件是良性的证据。403的处理尤其克制不会断言是气隙模式。因为 403 同样可能是过期/未授权的服务 token、被撤销的 scope或禁止文件分析的租户策略点错原因会让分析师去查网络而真正的修法在凭据上。成功时report是整块透传的provider 没发布的字段在这里读作unavailable而不是缺席。工具的 schema 里只声明了一个参数sha256描述中直接写明Never uploads the file. An unknown hash is not a clean verdict, and a failed lookup is not a clean verdict either: check the outcome field.七、HTTP API路由权限说明GET /api/v1/sandbox/providersthreat_intel:readprovider 列表、其同意状态与当前披露文本POST /api/v1/sandbox/lookupthreat_intel:read哈希查询永不上传POST /api/v1/sandbox/filesthreat_intel:write先查哈希仅在同意存在且confirm_upload为真时才上传POST /api/v1/sandbox/urlsthreat_intel:writeURL 提交。不受上传策略约束但仍受气隙约束GET /api/v1/sandbox/analyses/{provider}/{handle}threat_intel:read轮询PUT /api/v1/sandbox/consentsettings:write记录或撤回同意实现见 endpoints/sandbox.py。权限划分的依据是这个动作披露了什么而不是它读了什么开启上传是持续性的披露承诺所以用settings:write只有租户管理员持有而不是分析师的threat_intel:write。几处容易踩到的实现细节双重门。POST /files的confirm_upload是本次动作的确认租户同意是长期有效的授权两者都必需。这样一条长期同意不会把此后每一次调用都变成静默上传。该字段默认False。同意版本冲突返回 409。若uploads_enabledtrue且请求里的consent_text_version既非None也非当前版本路由会拒绝并提示页面加载后披露文本已变更请重新加载并阅读当前文本。一个停留在旧标签页的控制台不能把同意旧措辞记成同意当前措辞。气隙返回 403 而不是 404。provider 存在且已配置告诉运维不存在会把人送去补充本来就有的配置。文件体上限 32 MiB_MAX_UPLOAD_BYTES与 ingest 路径的附件上限保持一致非法 base64 或解码为零字节返回 422超限返回 413。GET /providers会带上authentication_verified。该值取自 provider 上可选的authentication_is_verified属性MalwareAnalyzer 恒返回False因此设置界面渲染为注意事项而不是绿色的勾。哈希查询的示例请求体只有一个字段外加可选的provider并且服务端会在进 provider 之前校验 64 位十六进制{ sha256: 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f, provider: capev2 }八、审计表两个问题两张表064_sandbox_upload_policy.sql 建了两张表因为以后会被问到的两个问题彼此都答不了对方CREATE TABLE aisoc_sandbox_upload_policy ( tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE, provider TEXT NOT NULL, uploads_enabled BOOLEAN NOT NULL DEFAULT FALSE, -- 本地 provider 也默认关 consent_text_version TEXT, consented_by UUID REFERENCES users(id) ON DELETE SET NULL, consented_at TIMESTAMPTZ, updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), PRIMARY KEY (tenant_id, provider) ); CREATE TABLE aisoc_sandbox_submissions ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE, provider TEXT NOT NULL, artifact_kind TEXT NOT NULL, -- file | url | hash sha256 TEXT, file_name TEXT, outcome TEXT NOT NULL, -- known|pending|not_seen|upload_refused|could_not_check refusal TEXT, -- UploadRefusal 的取值 reason TEXT NOT NULL DEFAULT , uploaded BOOLEAN NOT NULL DEFAULT FALSE, -- 仅在字节真的离开部署时为真 visibility TEXT, -- provider 自己措辞里的可见性 provider_handle TEXT, requested_by UUID REFERENCES users(id) ON DELETE SET NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() );主键是(tenant_id, provider)这个对因为同意问的是文件去哪。索引也为运维的实际查询设计(tenant_id, created_at DESC)、(tenant_id, sha256)的部分索引、以及WHERE uploaded的部分索引——最后这个直接服务列出真正发生过外发的记录。两张表都启用并FORCE了行级安全策略形如tenant_id current_tenant_id() OR current_tenant_id() IS NULL第二个分支让不绑租户的跨租户 worker留存清理、租户删除仍能读到数据去掉它这些任务会静默地什么都看不到。写入侧store.py 有三条值得注意的行为read_consent()把没有行读成False。同意是存在一份肯定记录所以没行和行里说否同义且不需要为了记一次拒绝而先建行。set_consent()在关闭同意时清空归属信息consented_by/consented_at/consent_text_version置空因为旧的同意不再描述当前状态留着会让人误以为有人同意了当前设置。record_decision()对审计失败采取 fail-soft审计插入失败不会让一次沙箱查询 500而是rollback后以warning级别记下没能存下的 outcome让缺行在日志管线里可见而不是无声消失。九、新增 provider 的完整流程文档给出的路径很短但每一步都有对应实现在services/api/app/services/sandbox/providers/下实现SandboxProvider。五个动词lookup_hash、submit_file、submit_url、poll以及描述自己的capabilities见 base.py。submit_file/submit_url有默认实现会抛本 provider 不接受提交aclose()也是具体的空实现注释解释了原因强制每个适配器写一个空覆盖会让那个本该关闭 client 的适配器更难被发现。在ProviderCapabilities里声明local与submissions_are_public_by_default并在registry.py中注册。这套包以外的任何地方都不应该知道新 provider 的名字。所有出站 URL 必须经过guard_outbound_url()base.py。它同时做两件事先跑气隙策略enforce_airgap_for_url再跑 SSRF 检查。allow_private由 provider 自己的local声明决定而不是由环境变量决定link-local169.254.0.0/16云元数据段在任何情况下都被拒绝——把私有放宽到能访问10.0.0.0/8上的沙箱不能顺带打开元数据服务。它返回 URL 本身让调用点写成client.get(guard_outbound_url(...))从而不可能误用未检查的字符串。域名解析时会检查每一个解析结果而不只是第一个一条同时含公网与私网地址的 A 记录否则会按先返回的那个侥幸通过。跑 scripts/check_sandbox_upload_policy.py。它会在以下情况失败某个适配器没有声明自己的local_check_providers_declare_locality任何同意类标志uploads_enabled、tenant_uploads_enabled、confirm_upload、uploaded等默认为Trueallow_upload是唯一例外因为它由路由显式传参真正的门是租户同意哈希查询不再先于上传analyse_file中lookup_hash的行号必须小于evaluate_upload后者必须小于submit_file某个异常处理器开始产出SandboxReport或outcomeknown/not_seen一个声明默认公开发布的 provider其同意文本里没有出现public、anyone与cannot be recalled。该 gate 还有一条容易被忽略的元规则空输入即失败。如果一次运行没有导入 policy 模块、没有读到任何 provider它会以退出码 2 结束并打印verified nothing而不是报告一个干净的仓库。十、运维核对清单上线前后可以按下面顺序逐项确认是否配了 provider什么都没配时注册表只有mock它的语料默认是空的所以首次运行会诚实地回答没被任何 provider 见过而不是编造一份清白记录。mock 产出的每份报告都带is_synthetic标记任何不带该 key 的合成裁决到达界面都属于缺陷。AISOC_AIRGAPPED是否传到了api只传给agents不算数API 自己的core/airgap.py与 sandbox registry 都要读它。气隙下托管 provider 是否显示为被排除 原因如果它直接消失了说明有人把names()和usable_names()用反了。同意是逐 provider 的且带版本号。查aisoc_sandbox_upload_policy确认每行的consent_text_version与当前CONSENT_TEXT_VERSION一致关闭同意后归属字段应为空。uploaded列是唯一的外发证据。想回答有没有客户文件去了第三方查aisoc_sandbox_submissions WHERE uploaded想回答某个附件到底怎么了查(tenant_id, sha256)两者都不需要读 provider 的日志。看到could_not_check就去查原因不要当结论。它涵盖超时、鉴权被拒、429限流、返回不可解析、分析失败——SandboxUnavailable.kind会区分network/auth/rate_limit/bad_response。是否需要为 MalwareAnalyzer 校准鉴权设置页会显示未验证。若你确认了真实 key 的方案改MALWAREANALYZER_API_KEY_HEADER与MALWAREANALYZER_API_KEY_PREFIX即可无需改代码MALWAREANALYZER_PRIVATE_SUBMISSIONS_CONFIRMED只在你自己验证过私有上传可用时设置。POST /api/v1/phishing/submit只接受摘要。它的attachment_hashes走同一条查找路径但只收 digest这条路由在提交的邮件上无人值守地运行一条能上传的无人值守路径离披露该租户收到的每一份附件只差一次配置失误。要让文件真正被分析请走/sandbox/files。这套设计的核心可以压缩成一句话能力声明在后端决定权在运维判断力留给阅读者。接口只负责把我看过了没有和我没能去看永远说成两句话因为把后者说成前者正是沙箱报告变成无人引爆的样本的健康证明的那一步。赞分享人工智能AI Agent网络安全后端前端【免费下载链接】AiSOCOpen-source AI Security Operations Center: alert fusion, LLM-agent triage, MITRE ATTCK investigation, and a replayable decision ledger for every agent step. Self-hostable, runs with no API keys, MIT licensed. Ships an MCP server for Claude, Cursor and Continue.项目地址https://gitcode.com/GitHub_Trending/ai/AiSOC点击查看免费下载相关推荐AiSOC 求助与问题上报完全指南文档检索、离线沙箱复现、Bug 提交与私有漏洞披露AiSOC 求助与问题上报完全指南文档检索、离线沙箱复现、Bug 提交与私有漏洞披露 本文以仓库根目录的 SUPPORT.md https://link.gi人工智能AI Agent网络安全后端前端AiSOC Tenable.io 连接器接入指南凭据配置、漏洞发现入库与 KEV 暴露分析AiSOC Tenable.io 连接器接入指南凭据配置、漏洞发现入库与 KEV 暴露分析 本文以 AiSOC 的 Tenable.io 连接器文档为主线讲人工智能AI Agent网络安全后端前端Ralph 沙箱文件同步机制详解E2B 云沙箱的上传/下载过滤、.ralphignore 与删除安全模型Ralph 沙箱文件同步机制详解E2B 云沙箱的上传/下载过滤、.ralphignore 与删除安全模型 本篇技术指南以 ralph sandbox e2b开发工具CLI代码智能体自主智能体人工智能上一篇GitHub 汉化插件三步安装指南刷新一次界面变中文下一篇SeaTunnel 企业微信Enterprise WeChatSink 连接器Webhook 告警推送与配置实战创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?
咨询建站