人工智能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 的 Prisma Cloud 连接器文档为骨架讲清一件事如何用一个连接器实例把 Palo Alto Networks Prisma Cloud 上 CSPM、CWPP、CIEM、DSPM 四个面的开放告警拉进 AiSOC并完成鉴权、时间窗轮询、字段归一化、严重度映射、OCSF 归类与排障。读完后你能独立完成控制台侧的配置、理解每一次 poll 到底发了什么请求、看懂落到 AiSOC 里的每条告警字段从哪来并在could not exchange access keys for prisma cloud JWT、HTTP 403这类报错前快速定位原因。为什么一个连接器就能覆盖四个产品面Prisma Cloud 的/alert/v1/alertREST 端点把所有模块的发现聚合在同一个返回体里。因此 AiSOC 不需要为 CSPM、CWPP、CIEM、DSPM 各写一套配置也不存在某个子产品忘了开的问题——租户上没授权的模块自然就不会有对应类型的告警返回AiSOC 侧没有任何开关需要关掉。这条设计在源码里是一句注释就说清的prisma_cloud.py 的文件头明确写着 A single connector instance covers every Prisma Cloud surface — CSPM, CWPP, CIEM, DSPM — because the/alert/v1/alertendpoint aggregates findings across all of them.数据源Prisma Cloud 端点说明AlertsPOST /alert/v1/alert全部开放告警按上一次轮询窗口取数最新优先事件归一化后统一打上source: prisma_cloud同时把 Prisma Cloud 的原始报文完整保留在raw_event里。这一点很关键playbook 想按 policy 类型或 finding 子类型做精细化处置时不需要 AiSOC 为每个字段都建索引直接读raw_event即可。连接器在 AiSOC 里的身份schema、能力与调度Prisma Cloud 连接器是一个标准的BaseConnector子类在 prisma_cloud.py 中声明了三个身份属性connector_id prisma_cloud connector_name Prisma Cloud connector_category cloud并在 connectors/init.py 中被显式导入注册。AiSOC 的连接器注册表刻意采用饿汉式导入而不是pkgutil动态发现理由写在init.py导入关系在 code review 里可审计导入错误在服务启动时暴露而不是在第一次请求时暴露同时对 mypy 和 IDE 跳转友好。能力声明只有一项classmethod def capabilities(cls) - tuple[Capability, ...]: return (Capability.PULL_ALERTS,)PULL_ALERTS属于Capability枚举中的 READ 类被动拉取动词。base.py 里解释了为什么把PULL_*与QUERY_*、ENRICH_*分开命名PULL_ALERTS表示数据湖里已经落地的QUERY_LOGS表示现在就去问源端ENRICH_USER表示单实体一次往返。这个区分让 Agent 在规划动作时能估算成本与延迟。没有ISOLATE_HOST、BLOCK_IP这类动词等于在类型层面声明了只读——这也是文档中 Live actions 一节的实现依据。若某实例被运营者用allowed_capabilities白名单收窄effective_capabilities()会与类声明取交集交集为空表示该实例仅供轮询、不供 Agent 使用。schema 由类方法自描述直接喂给前端Add connector向导因此向导表单不会和后端漂移ConnectorSchema( connector_idprisma_cloud, connector_namePrisma Cloud, categorycloud, description... Pulls open alerts across CSPM, CWPP, CIEM, and DSPM surfaces via the v1 REST API., docs_url/docs/connectors/prisma-cloud, fields[...], )字段的Field定义在 base.pyto_dict()会剥掉值为None的键所以线上 JSON 很紧凑前端不必特判缺失与null。前置条件访问密钥与区域 API 端点开工前需要三样东西一个有管理员或 System Admin 权限的 Prisma Cloud 租户。一对 Prisma Cloud访问密钥accessKeyId—— 访问密钥 IDUUID 格式。secretKey—— 与之匹配的密钥。与你租户所在区域对应的 API 端点例如https://api.prismacloud.io、https://api2.eu.prismacloud.io、https://api.gov.prismacloud.io。这个值在 Prisma Cloud 控制台的System → API Endpoints里查。访问密钥在控制台的Settings → Access Control → Access Keys → Add New创建。密钥只在创建时展示一次务必当场复制到密码管理器。一个常见误解值得单独点名控制台 URL 不是 API URL。把浏览器地址栏里的域名填进api_url是最典型的一类配置错误。配置步骤第一步创建访问密钥在 Prisma Cloud 控制台进入Settings → Access Control → Access Keys → Add New。给密钥起个可追溯的名字比如aisoc-prod并选择有效期——与你们的密钥轮换策略对齐。把Access Key ID与Secret Key存入密码管理器。确认密钥绑定的角色至少对Alerts资源有读权限。内置的System Admin和Account Group Admin都能用若要最小权限自建一个仅含Alerts: View的自定义角色。第二步在 AiSOC 中添加连接器Connectors → Add connector → Prisma Cloud。API URL—— 填System → API Endpoints里给出、与你区域匹配的地址如https://api.prismacloud.io。Access Key ID与Secret Key—— 粘贴第一步拿到的值。Compute API URL—— 留空。AiSOC 只消费统一的/alert端点该端点已经把 ComputeTwistlock的运行时发现收敛进来。Test connection—— AiSOC 会用访问密钥通过POST /login换取一个短期 JWT并确认鉴权成功。Save。配置字段参考下表由连接器的schema()生成是Add connector向导渲染的同一份来源字段标签类型必填默认值说明api_urlAPI URLstring是—Prisma Cloud REST API 的区域化基础 URL。取值见 Prisma Cloud → System → API Endpoints如api2.eu、api.gov。access_key_idAccess Key IDstring是——secret_keySecret Keysecret是—静态加密存储compute_urlCompute API URL (optional)string否—租户专属 Compute (Twistlock) API 基础 URL。留空——当前版本只消费统一的/alert端点。compute_url的占位符在源码里给出了格式提示https://us-east1.cloud.twistlock.com/tenant-id它是一个可选字段requiredFalse单元测试 test_prisma_cloud.py 明确断言了这一点注释写着 compute_url must be optional; v7.1.0 only consumes the unified /alert endpoint。:::note 凭据处理secret_key在写入数据库行之前就被凭据保险库静态加密只在轮询时解密该值不会被日志记录也不会被 API 返回。详见 凭据保险库。 :::凭据加密与测试连接的真实链路secret_key之所以标为secret类型不只是给前端渲染一个掩码输入框。AiSOC 在应用层用 FernetAES-128-CBC HMAC-SHA256加密连接器凭据密文存放在connector_instances.auth_config里主密钥来自AISOC_CREDENTIAL_KEY环境变量。设计意图写在 credentials.md数据库自身加密只防磁盘失窃不防只读角色泄露、备份泄露或副本配置错误应用层加密则让一份pg_dump在没有主密钥时毫无价值。这意味着两个服务必须共享同一个AISOC_CREDENTIAL_KEYAPI 服务负责写密文连接器服务在取数时解密。密钥不一致时轮询会以InvalidToken失败。向导里的Test connection按钮并不在连接器服务内部完成全部工作它走的是连接器服务的一个无状态路由 router.pyAPI 服务查出实例行或直接使用向导里尚未落库的新凭据解密auth_config。把明文凭据与connector_config一起 POST 到连接器服务。连接器服务把两个字典合并成构造参数{**payload.auth_config, **payload.connector_config}后者不能覆盖前者属于纵深防御在构造对象之前、在任何 socket 打开之前调用refuse_internal_destinations(kwargs)。构造PrismaCloudConnector(**kwargs)并await connector.test_connection()。第 3 步值得展开它会遍历所有 URL 形态的参数交给 ssrf_guard 校验。任何指向云元数据、回环地址或部署内网服务的api_url都会被直接拒绝并返回 422而不是先请求再把响应反射回来。注意其细节——DNS 解析失败socket.gaierror被视为解析不了而非策略拒绝因此不会误判。轮询机制每次 poll 重新换 JWT时间与频率的约定默认间隔300 秒。每次 poll 都会调用POST /login换取一个新的 JWT。Prisma Cloud 的令牌是滑动 TTL重新鉴权成本很低每次 poll 都换可以彻底避开过期窗口附近的缓存失效问题。取数窗口是最近interval秒使用timeRange.type absolute配合 epoch 毫秒的startTime/endTime。只拉status open的告警resolved / snoozed / dismissed 在源端就被过滤掉。结果集上限200 条/次。如果租户在 5 分钟内稳定产出超过这个量应调小轮询间隔而不是调大上限——这样每次请求都稳稳落在 Prisma Cloud 的 API 超时之内。这三条在源码里都能对上。默认值与上下界定义在 scheduler.py_DEFAULT_POLL_INTERVAL_S 300 _MIN_POLL_INTERVAL_S 30 _MAX_POLL_INTERVAL_S 86400 # 24 hours def _coerce_poll_interval(connector_config: dict[str, Any]) - int: raw connector_config.get(poll_interval_seconds, _DEFAULT_POLL_INTERVAL_S) try: seconds int(raw) except (TypeError, ValueError): return _DEFAULT_POLL_INTERVAL_S if seconds _MIN_POLL_INTERVAL_S: return _MIN_POLL_INTERVAL_S if seconds _MAX_POLL_INTERVAL_S: return _MAX_POLL_INTERVAL_S return seconds于是poll_interval_seconds被钳制在30 秒到 86400 秒之间非法值比如not-a-number回落到 300。这些边界在 test_scheduler.py 里有对应测试。关键的一点调度器把轮询间隔同时当作取数窗口。它在 scheduler.py 里写下since_seconds _coerce_poll_interval(target.connector_config) raw_events await connector.fetch_alerts(since_secondssince_seconds)所以 300 秒一次 poll取的就是最近 300 秒把间隔改成 60 秒窗口也同步变成 60 秒。此外还有一条故障恢复回填路径当连接器中断至少 30 分钟后恢复会触发一次带扩展窗口的一次性 poll窗口上限 24 小时_MAX_BACKFILL_LOOKBACK_S并叠加 5 分钟缓冲_BACKFILL_LOOKBACK_BUFFER_S覆盖最后一次成功 poll与last_outage_at之间的空隙。上限的存在是为了避免一次三天中断变成一次三天跨度的查询、被源端限流或直接拒绝。一次 poll 的完整调用链fetch_alerts()在 prisma_cloud.py 中的行为可以逐步还原调_login()换 JWT失败则返回空列表而不是抛异常让轮询循环优雅降级由调度器在下一个周期重试。计算end now(UTC)、start end - timedelta(secondssince_seconds)。组装如下请求体结构与源码逐字段一致{ timeRange: { type: absolute, value: { startTime: 1735689300000, endTime: 1735689600000 } }, filters: [ { name: alert.status, operator: , value: open } ], sortBy: [alertTime:desc], limit: 200 }POST {api_url}/alert/v1/alert请求头带x-redlock-auth: token这就是 Prisma Cloud 的鉴权头名见_headers()。超时时间为30 秒登录请求为15 秒。非 200 时记录prisma_cloud.fetch_failed并返回空列表。解析返回体后逐条normalize()。第 6 步有一个容易被忽略的兼容处理/alert/v1/alert在不同区域的租户上返回体可能是裸数组也可能是{items: [...]}信封源码还额外接受alerts键if isinstance(payload, list): items payload elif isinstance(payload, dict): items payload.get(items) or payload.get(alerts) or [] else: items []对应测试test_fetch_alerts_handles_bare_list_envelope就是在模拟区域差异注释直言 Some Prisma Cloud regions return a bare list instead of the{items: [...]}envelope; the connector must accept both.字段归一化落到 AiSOC 里的每条告警长什么样normalize()把 Prisma Cloud 的告警报文压成 AiSOC 的规范信封。以一条公开可读的 S3 桶为例输入是{ id: alert-1, alertTime: 1735689600000, policy: { name: Public S3 bucket, description: S3 bucket is publicly readable, severity: critical }, resource: { name: logs-bucket, rrn: rrn::s3:us-east-1:123:bucket/logs-bucket, cloudType: aws, regionId: us-east-1 } }输出的规范字段与取值来源如下AiSOC 字段取值来源说明source固定prisma_cloud连接器 ID下游按此分派 OCSF profilecategory固定cloud与connector_category一致external_idraw.id→ 回退raw.alertId厂商告警 ID去重与回链的关键titlepolicy.name→ 回退raw.name→ 回退Prisma Cloud alert空值也有保底文案descriptionpolicy.description→ 回退raw.description→ 空串—severitypolicy.severity→ 回退raw.severity缺省medium见下一节映射hostnameresource.name资源名如实例 ID、桶名cloud_resourceresource.rrn→ 回退resource.id云资源唯一标识跨云统一寻址cloud_platformresource.cloudType如awscloud_regionresource.regionId→ 回退resource.region区域字段有历史变体rule_namepolicy.name与title同源便于按策略聚合raw_event整个原始对象完整保留供 playbook 深挖created_atalertTime→ 回退firstSeen数字按 epoch 毫秒转 ISO-8601时间戳的转换是防御式的alertTime通常是 epoch 毫秒AiSOC 下游期望 ISO-8601 字符串因此代码判断类型后再转换但部分历史报文直接给 ISO 字符串此时原样透传created_at raw.get(alertTime) or raw.get(firstSeen) if isinstance(created_at, int | float): created_at datetime.fromtimestamp(created_at / 1000, tzUTC).strftime(%Y-%m-%dT%H:%M:%SZ)test_normalize_handles_iso_timestamp_passthrough覆盖了后者test_normalize_critical_preserves_critical覆盖了前者并断言created_at 2025-01-01T00:00:00Z。严重度映射文档表与当前源码的一处偏差文档给出的映射是一张 4 档阶梯到 AiSOC 标准档位的对照表Prisma Cloud 严重度文档中的 AiSOC 严重度criticalhighhighhighmediummediumlowlowinformationalinfo文档解释的理由是AiSOC 不暴露独立的 critical 档位因此把critical收敛进high并把原始档位保留在raw_event.policy.severity下。但当前仓库源码已经不是这个行为。 prisma_cloud.py 里的映射表是_SEVERITY_MAP: dict[str, str] { critical: critical, high: high, medium: medium, low: low, informational: info, info: info, }2025-01-01 的那条单测直接断言out[severity] critical注释写着 Prisma Cloud critical must map directly to AiSOC critical so P1 SLAs apply措辞是 never silently downgrade tohigh, since AiSOC now exposes a dedicated 5th tier for P1 work。交叉验证也支持5 档这一现状告警升级接口 alerts.py 使用的阶梯是[info, low, medium, high, critical]融合服务的推广判定should_promote()把severity_id 4视为可达OCSF 规范侧_canonicalSeverityMap也是critical: 5, high: 4, medium: 3, low: 2, info: 1。因此实操建议是以源码为准critical会保留为critical文档中那张表应视为旧版4 档时代描述。这不影响raw_event.policy.severity的保留承诺——原始档位始终在raw_event里可取。同理无法识别的严重度一律回落到mediumtest_normalize_falls_back_to_medium_for_unknown_severity断言了never silently drop而 Live actions 一节标注的 v7.3.1 与compute_url帮助文本里的 v7.1.0也都是版本演进留下的历史标注当前仓库 VERSION 为 20.1.0capabilities()仍只声明PULL_ALERTS即只读定位没有改变。覆盖范围四个模块各自带来什么统一的/alert端点包含你租户已授权的所有模块的发现模块在 AiSOC 中看到的内容CSPMCloud Security PostureS3 桶错配、公网数据库、IAM 漂移、网络暴露面CWPPWorkload Protection镜像漏洞、运行时漂移、主机姿态发现CIEMIdentity Entitlements过度授权身份、闲置权限、角色链风险DSPMData Security Posture敏感数据暴露、分类发现、数据流风险租户未授权的模块不会产生对应类型的告警AiSOC 侧无需关闭任何东西。进入数据湖之后OCSF 归类与必然提升归一化只是第一站。事件进入 ingest 后要做 OCSF 归类而归类结果直接决定这条事件是否变成分析师队列里的告警。ocsf_classes.go 的头部注释讲清了机制should_promote()在OCSF category 2Findings或severity_id 4时提升为告警category 等于 class uid 除以 1000。也就是说连接器事件携带的 class 决定了它是进队列还是只留在湖里。Prisma Cloud 在这张表里被显式归入故意的 2001 Security Findingprisma_cloud: {genericReason: cloud security alerts: already judged by the vendor},同一组里还有 CrowdStrike、SentinelOne、Wiz、Orca、Lacework、AWS GuardDuty、GCP SCC 等。genericReason字段不是没人看过的逃生门而是要求写明理由的字段——这里的理由是这些连接器返回的是厂商已经判定为发现的结果所以 category 2 与无条件提升是正确结果而不是疏漏。这一点对排障有直接价值如果你发现 Prisma Cloud 的告警看起来什么都进得来那是设计如此如果你担心低危噪声淹没队列正确的手段不是改 class而是下一节的过滤规则或下游的评分。去重、重放与游标PrismaCloudConnector没有声明checkpoint_time_field/checkpoint_id_field按 base.py 的checkpoints()语义它的返回值是False——即重启后会重读其重叠窗口这是安全的方向代价是长时间中断会丢失窗口之外的事件。重叠窗口带来的重复投递由 ingest 侧的确定性事件 ID 收敛。normalizer.go 的generateEventID用(connector_id, tenant_id)加上一个稳定的厂商标识按external_id→event_id→id→_cd优先级派生 UUIDv5base : fmt.Sprintf(%s:%s, raw.ConnectorID, raw.TenantID) for _, field : range []string{external_id, event_id, id, _cd} { if v, ok : raw.Payload[field].(string); ok v ! { return uuid.NewSHA1(uuid.NameSpaceOID, []byte(base:fieldv)).String() } }注释特别指出ReceivedAt被刻意排除在这条路径之外——它每次 poll 都会变以前正是它让 ID 在每次轮询时改变。若确实没有稳定标识才回退到事件时间 payload 内容哈希保证字节级重放仍然收敛而同一时间戳的两条不同内容事件保持可分。对 Prisma Cloud 而言normalize()产出的external_id来自raw.id或raw.alertId因此重叠窗口与故障回填都不会造成重复告警。反过来说如果某个租户返回的告警缺少id/alertId去重就会退化为内容哈希此时需要关注上游字段完整性。用过滤规则在边缘降噪调度器在每个 poll 的归一化之后、推送 ingest 之前会执行连接器配置里的filter_rules。实现见 filter_rules.py规则形态刻意保持极小filter_rules: - field: severity op: eq value: info action: drop - field: rule_name op: contains value: test alert action: drop支持的操作符与federated.query共用一套词汇避免运营者学两种方言eq、ne、contains、starts_with、ends_with、in动作只有drop与keep。语义与 iptables 一致——自上而下、首个匹配生效、无匹配默认保留。缺失字段被视为不匹配而非报错一个引用了厂商已改名字段的规则不会把轮询循环打挂未知操作符一律拒绝丢弃宁可多留也不静默丢事件。对 Prisma Cloud 场景典型用法是压掉低价值的合规提示比如某个高频的informational策略把热门存储留给真正的姿态风险。注意filter_rules属于调度器专用键router.py 与调度器都会在构造连接器前把它剔除不会误传给__init__。只读定位与处置路径Prisma Cloud 连接器目前是只读的。云侧发现的遏制动作通过其他连接器完成AWS Security Hub —— 仅 AWS 部署下的原生发现聚合。AWS GuardDuty —— AWS 威胁发现。Cloudflare —— 边缘侧处置。GCP Cloud Audit —— GCP 控制面审计。这个读一个源、动另一个源的分工在架构上是刻意的PrismaCloudConnector的capabilities()只返回PULL_ALERTSAgent 层拿不到任何动能动词因此不存在以为能隔离、实际调不到执行器的落差。排障手册could not exchange access keys for prisma cloud JWT——accessKeyId/secretKey不匹配、访问密钥已过期或api_url指向的区域与租户不符。这段错误文案就是test_connection()在_login()返回None时给出的固定字符串。直接验证curl -X POST https://api.prismacloud.io/login \ -H Content-Type: application/json \ -d {username:YOUR_ACCESS_KEY_ID,password:YOUR_SECRET}返回 200 且带{ token: ... }说明凭据可用问题在 AiSOC 侧字段最常见的还是区域 URL 填错。若返回 200 但没有token字段源码也会判为失败——test_test_connection_handles_login_returning_no_token专门模拟了密钥被禁用时 Prisma Cloud 返回 200 却无 token的实测行为。/alert/v1/alert返回HTTP 403—— 密钥绑定的角色缺少Alerts: View。检查Settings → Access Control → Access Keys → 你的密钥 → Role确认权限存在。两次 poll 之间events_added: 0—— 租户在过去 5 分钟内没有产生新的开放告警。resolved / snoozed 已在源端被alert.status open过滤掉安静租户上这是预期的稳态不是故障。events_added由调度器在 ingest 接受后写入见 scheduler.py 与 connector_repo.py它统计的是被接受的事件数因此过滤规则丢弃的事件不会出现在这里。EU / Gov 区域租户取不到数据—— 确认 API URL 与区域匹配EU 租户用api2.eu.prismacloud.ioGov 用api.gov.prismacloud.io。再次强调控制台 URL 不是 API URL。连接器显示不健康但日志没有明显报错—— 依次怀疑三处凭据解密失败connector.scheduler.decrypt_failed主密钥不一致、构造参数不匹配connector.scheduler.bad_config通常是TypeError、目标地址被 SSRF 策略拒绝connector.scheduler.destination_refused。第三种在企业内网场景需要留意若api_url落在私有网段需要显式设置AISOC_SSRF_ALLOW_PRIVATE1。保存后轮询没有立即生效—— 调度器以 60 秒为周期重读连接器表_DEFAULT_RELOAD_INTERVAL_S并通过配置签名比对决定是否重排任务。新实例最多等一个重载周期启动时会立即触发一次重载所以不会等满 60 秒才开始。本地验证连接器行为仓库提供了完整单测用respx拦截 HTTP不会真的打到 Prisma Cloudcd services/connectors python -m pytest tests/test_prisma_cloud.py -v覆盖的关键断言包括schema 必含四个字段且secret_key.type secretcompute_url可选critical保留为criticalinformational映射为infoISO 时间戳透传未知严重度回落mediumitems信封与裸数组两种返回体都能解析登录失败或告警端点 5xx 时返回空列表而不抛异常。如果想手工验证一条真实告警的归一化结果可以直接实例化连接器并调用normalize()from app.connectors.prisma_cloud import PrismaCloudConnector c PrismaCloudConnector(https://api.prismacloud.io, KEY_ID, SECRET) out c.normalize({ id: alert-1, alertTime: 1735689600000, policy: {name: Public S3 bucket, severity: critical}, resource: {name: logs-bucket, rrn: rrn::s3:us-east-1:123:bucket/logs-bucket, cloudType: aws, regionId: us-east-1}, }) print(out[severity], out[created_at], out[cloud_resource])这段代码只依赖连接器模块本身不需要数据库或凭据保险库适合在接入前确认字段是否符合你的 playbook 预期。相关连接器Wiz —— 另一条 CNAPP 路径云图上下文更丰富。Lacework —— 侧重工作负载与合规的 CNAPP 方案。AWS Security Hub —— 纯 AWS 部署下的原生发现聚合。想了解连接器整体模型自描述 schema、凭据加密、轮询可观测性可回到 连接器总览想了解凭据如何生成、轮换与在 K8s / Fly.io / ECS 上放置主密钥见 凭据保险库与密钥管理。赞分享人工智能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 Microsoft Defender (XDR) 连接器通过 Microsoft Graph Security API 接入 M365 Defender 统一告警AiSOC Microsoft Defender XDR 连接器通过 Microsoft Graph Security API 接入 M365 Defende人工智能AI Agent网络安全后端前端AiSOC Devo 连接器实战将 Devo SIEM 告警接入告警融合与 AI 分诊流水线AiSOC Devo 连接器实战将 Devo SIEM 告警接入告警融合与 AI 分诊流水线 本文围绕 AiSOC 仓库中的 Devo 连接器文档 devo.人工智能AI Agent网络安全后端前端Orca Security 接入 AiSOC 实战指南统一 /api/alerts 拉取 CNAPP 告警与归一化实现Orca Security 接入 AiSOC 实战指南统一 /api/alerts 拉取 CNAPP 告警与归一化实现 Orca Security 是典型的人工智能AI Agent网络安全后端前端上一篇如何安装codex-first-customer-finder-skill一条npx命令5分钟部署你的首批客户挖掘技能下一篇EasyInvoicePDF分享链接编码原理解析一张完整发票如何被压缩进一条短URL创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考