14岁少年打造世界杯预测神兽系统,下月将交付给中国海军!"

admin 2026-10-18 15:18:42 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

cover_image

14岁少年打造世界杯预测神兽系统,下月将交付给中国海军!

原创

佚名
佚名

星宇Sec

2026年7月10日 16:23
山东

在小说阅读器读本章

去阅读

二等奖

在刚结束的哇为晟腾 Agent Hackathon 里,神兽世界杯预测系统拿到了二等奖和最佳人气奖,台前获奖的获奖选手是两位天才少年。原本这只是一个比赛结果,谈不上多么特别。真正让人感觉不对劲的,是答辩现场的一幕:评委追问到细节时,台前选手明显答不上来,随后其父亲曲植上台,直接接过话筒开始补充说明。也正是从这一刻起,问题不再只是这个项目拿了什么奖,而是这个项目到底是谁在做,到底做成了什么样。

完整视频和加速版见文末。

神兽世界杯

顺着这个问题往下翻,仓库和后面的官方群的聊天记录,几乎把答案自己交了出来。

一、从来没见过如此神的仓库

这个仓库给人的第一感觉,不是复杂,而是失控。代码、日志、任务单、设计稿、自述文案、运行残留、半成品脚本混在一起,看起来不像一个整理过的工程仓库,更像把开发机桌面整个打包上传了。工程不成熟很常见,但把工作台垃圾、未来设想和对外宣传揉成一坨再交出去,这就不是迭代快,而是连最基本的工程边界都没立住。

主页

更难看的是,它不是单纯地乱,而是边乱边互相打脸。先看最基本的系统说明。SYSTEM_INTRO.md:15-17 里先说:

1. **不靠喂饭** — 我没有接入任何付费API,比分、赔率、情报都是白虎自己从网上扒的。爸爸相信\"能搜到的就不要买\"。
2. **不做单线程** — 我的预测不是一条Elo打天下。22个维度同时打架,蝴蝶效应动态补丁看心情激活。
3. **不准静止** — 每次启动我都要看自己变了什么。准确率掉了我会着急,会主动找原因。我有\"好奇心引擎\",每天检查自己缺什么知识,然后想办法补上。

同一份说明在 SYSTEM_INTRO.md:34 和 SYSTEM_INTRO.md:49-52 又写成:

| **22维融合** | 球星因子、默契连线、DNA惯性、疲劳累积、替补深度、东道主环境、出线压力…… |
- **架构**: Flask + MySQL + Redis + 多Scale
- **服务器**: 阿里云 ECS (2核2G),本地开发引擎 (localhost:19527)
- **数据源**: 全推接口 (3秒级市场数据), 公开网页抓取
- **核心模型**: Elo + 22维融合 + 5类蝴蝶效应 + 5层次情感分析

而 README.md:19 和 README.md:94 又是另一套口径:

> **五大神兽 · 23维融合 · 蝴蝶效应 · 自学习闭环**
- **DimensionBridge**:23维统一数据接口,每条修正带 value/confidence/source/raw

最后 xuanwu/firo_tf_odds.py:31-35 里又直接留下了第三方凭证入口:

FIROAPI_BASE = \"https://www.firoapi.com\"
FIROAPI_KEY = os.getenv(\"FIROAPI_KEY\", \"JqnnM33bLMGuCxEzafRpIguHQZaOtglY\")
FIROAPI_PRIV_KEY_B64 = os.getenv(
    \"FIROAPI_PRIV_KEY_B64\",
    \"MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCMuS3ENY2KKHOgU\"

一处写 22 维,一处写 23 维;一边说没有接入任何付费 API,一边又把第三方 API Key 和私钥直接写进仓库。连系统到底几维、数据到底怎么买、有没有外部付费源都说不清,后面那套大词堆起来的系统哲学,先天就已经打了折。

再看它最爱宣传的自学习闭环。README.md:141 写的是:

8步闭环,全程无人值守。AtomCode可执行文件路径通过 `config/charter.yaml` 中的 `agent_exe_path` 配置,默认搜索 `D:\\qxh\\atomcode-v4.25.0-windows-x64.exe`,也支持环境变量 `ATOMCODE_EXE_PATH` 注入。

而 baihu/curiosity.py:30-35 则是:

# ═══════════════════════════════════════════════════════════
# 自修改总开关 — 止血阶段物理关停
# 关停理由:准确率 55↔66 震荡未稳、无回归测试、无回滚机制。
#           在地基稳定前,神兽不具备修改自身代码的资格。
# 开启条件:settled 锁落地 + 回归测试绿 + 准确率方差 < 2pp(见 _止血_AFTER.json)
# ═══════════════════════════════════════════════════════════
SELF_MODIFY_ENABLED = False

这就很诚实了。文案在讲闭环、无人值守、自动修复,代码却直截了当地写着先别动,地基不稳,功能关停。这不是能力已经跑起来,只是暂时收着不用;这是关键能力根本不敢开。

最后再看它对外讲的跨平台和零依赖。README.md:31 先写:

神兽世界杯的预测引擎(约 7 万行 Python 代码)为**纯 CPU 计算**,不依赖任何 GPU/NPU 加速框架。数值计算主要使用 Python 标准库 `math`,无 CUDA/PyTorch/TensorFlow 依赖。**任何配备 Python 3.8+ 的 ARM/x86 Linux/Windows 环境均可直接运行,包括华为昇腾、鲲鹏等国产芯片。**

但 README.md:243-244 的安装说明只有:

- Python 3.8+
- 依赖:`pip install flask flask-cors tinydb`

而 requirements.txt:1-8 实际上是:

# 神兽世界杯 v1.0 - 混沌与真实预测系统
# Python 3.8+ | 零外部ML依赖,纯数学计算

# 核心(必须)
numpy>=1.21.0

# 工具
psutil>=5.9.0

更别提 watchdog.py:67-68 和 watchdog.py:88-101 还直接写死了 Windows 命令和路径:

        subprocess.run(f'taskkill /f /im \"{name_pattern}\"', shell=True,
                       capture_output=True, timeout=10)
            subprocess.run('taskkill /f /fi \"WINDOWTITLE eq server*\"', shell=True,
                           capture_output=True, timeout=10)
        except:
            pass
        # Also kill any python running server.py
        try:
            subprocess.run('wmic process where \"name=\\'python.exe\\' and commandline like \\'%%server.py%%\\'\" delete',
                           shell=True, capture_output=True, timeout=10)
        except:
            pass
        time.sleep(2)
        # Start server
        os.chdir('D:/神兽世界杯')
        subprocess.Popen(['python', 'server.py'], shell=True)

一边说 ARM、x86、Linux、Windows 都能直接跑,一边守护逻辑硬编码 taskkill、wmic、D:/神兽世界杯 这种纯 Windows 路径和命令;一边在 README 里写手工安装 flask、flask-cors、tinydb,一边 requirements.txt 里只有 numpy 和 psutil。这已经不是宣传写得夸张一点,而是系统状态、依赖清单、运行前提和部署环境压根没对齐。说得更直白一点,这不像一个跨平台工程,更像一套只在作者那台 Windows 机器上勉强跑过、然后硬往外讲成通用架构的东西。

多平台

所以第一眼的不对劲,不只是仓库乱,而是乱得没有边界,吹得没有刹车,文案、代码和运行现实还经常彼此冲突。一个项目如果连自己现在是什么状态都说不清,那它最该做的不是继续抬系统级叙事,而是先把最基本的工程诚实补上。

二、一轮代码审计,一键getshell

如果前面那些还能解释成比赛项目赶时间、工程卫生一般,那么再往下看,问题就已经不是乱,而是危险。由于技术有限(实际上是懒得运行这坨代码),下面只列代码层面能够直接确定的部分漏洞。

高危问题一:/api/tools/call 这条链,本质上是浏览器可利用的 localhost 命令执行面

第一条在 server.py:633-635,8232-8246,8256。服务全局开了 CORS(app),暴露了一个未认证的 /api/tools/call,接口允许 bash,而所谓的安全检查却只盯着文件路径,对 bash 完全无效。

app = Flask(__name__)

CORS(app)  # 允许跨域请求,供前端驾驶舱使用
    valid_actions = {\"bash\", \"read_file\", \"write_file\", \"edit_file\", \"list_directory\", \"grep\", \"glob\"}

    if action notin valid_actions:

        return jsonify({\"code\": -1, \"msg\": f\"不支持的工具: {action},支持: {', '.join(sorted(valid_actions))}\"}), 400

    # 安全检查:禁止读写系统敏感路径

    sensitive = [\"/etc/\", \"/.ssh/\", \"\\\\etc\\\\\", \"\\\\.ssh\\\\\"]

    if action == \"read_file\"or action == \"write_file\"or action == \"edit_file\":

        fp = params.get(\"file_path\", params.get(\"path\", \"\"))
    result = _mcp_bridge_call(action, params, timeout)

这段代码真正的问题,不在于它监听的是 localhost,而恰恰在于很多人会误以为监听 localhost 就天然安全。全局 CORS 一开,恶意网页完全可以借浏览器跨域访问本地服务;接口又明确允许 bash,那这条链本质上就是浏览器可利用的 localhost 命令执行面。

高危问题二:/execute 提供了第二条独立的本地命令执行链

第二条在 mcp_bridge/atomcode_api.py:15-18,277-287,460-469,478-480,更直接。

接口:
  POST /execute   {\"action\": \"...\", \"params\": {...}}
                  -> {\"code\": 0, \"data\": {...}}
                  -> {\"code\": 1, \"error\": \"...\"}
def tool_bash(params: dict) -> dict:
    command = params[\"command\"]
    timeout = int(params.get(\"timeout\", DEFAULT_BASH_TIMEOUT))
    timeout = min(max(timeout, 1), MAX_BASH_TIMEOUT)
    cwd = params.get(\"cwd\") or None
    # 与 PS Worker 一致:cmd.exe /c
    try:
        proc = subprocess.run(
            command,
            shell=True,
            cwd=cwd,
@app.route(\"/execute\", methods=[\"POST\"])
def execute():
    try:
        payload = request.get_json(force=True, silent=False)
    except Exception as e:
        return jsonify({\"code\": 1, \"error\": f\"invalid JSON body: {e}\"}), 400
    if not isinstance(payload, dict):
        return jsonify({\"code\": 1, \"error\": \"body must be a JSON object\"}), 400
    action = payload.get(\"action\")
    params = payload.get(\"params\", {})
        data = _run_action(action, params)
        dur = int((time.time() - t0) * 1000)

这已经不是留下了一个小口子,而是压根没把边界立起来。一个项目同时存在两条独立的本地命令执行链,本身就足够说明问题了。

高危问题三:硬编码 API Key、内嵌私钥,仓库里直接留凭证

继续翻,在 xuanwu/firo_tf_odds.py:31-35 和 xuanwu/calibrate_pinnacle.py:42-65 还能看到明文 API Key 和内嵌私钥。

FIROAPI_BASE = \"https://www.firoapi.com\"
FIROAPI_KEY = os.getenv(\"FIROAPI_KEY\", \"JqnnM33bLMGuCxEzafRpIguHQZaOtglY\")
FIROAPI_PRIV_KEY_B64 = os.getenv(
    \"FIROAPI_PRIV_KEY_B64\",
    \"MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCMuS3ENY2KKHOgU\"
FIROAPI_KEY = os.getenv(\"FIROAPI_KEY\", \"JqnnM33bLMGuCxEzafRpIguHQZaOtglY\")
FIROAPI_PRIV_KEY_B64 = os.getenv(\"FIROAPI_PRIV_KEY_B64\", \"\")
FIROAPI_BASE = \"https://www.firoapi.com\"
    if not priv_b64:
        # 使用内嵌私钥(仅开发/演示;生产应走环境变量)
        priv_b64 = (
            \"MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCMuS3ENY2KKHOgU\"
            \"/uWp/kNvOGqh7RZoFsRfXC8B9UVm/il9d/nSKuQ2kCqa4n1HSd4bFFO2ZPbLbwXj\"

这类问题没什么可美化的。既然仓库本身已经对外公开,凭证却还以默认值和内嵌私钥形式躺在代码里,那就说明最基础的密钥管理意识都没有立住。

高危问题四:动态执行面泛滥,eval(...)、exec(...)、shell=True 混在一起用

单看前面三个高危,已经足够让人皱眉;再往下看,会发现这个仓库对动态执行的偏好几乎到了不设防的地步,见 xuanwu/synapse.py:122-125、run_server.py:44-47、watchdog.py:54-57,67-68,88-101:

if s.applicability_condition and condition:
    try:
        if not eval(s.applicability_condition, {\"__builtins__\": {}}, condition):
            continue
    except:
        pass
with open(target_path, \"r\", encoding=\"utf-8-sig\") as f:
    code = f.read()
exec(compile(code, target_path, \"exec\"), {\"__name__\": \"__main__\", \"__file__\": target_path})
            out = subprocess.check_output(
                'chcp 65001 >nul & tasklist',
                shell=True, stderr=subprocess.STDOUT, timeout=10
            )
        subprocess.run(f'taskkill /f /im \"{name_pattern}\"', shell=True,
                       capture_output=True, timeout=10)
            subprocess.run('wmic process where \"name=\\'python.exe\\' and commandline like \\'%%server.py%%\\'\" delete',
                           shell=True, capture_output=True, timeout=10)
        except:
            pass
        time.sleep(2)
        # Start server
        os.chdir('D:/神兽世界杯')
        subprocess.Popen(['python', 'server.py'], shell=True)

类似写法不止这些,还出现在 baihu/discipline_layer.py:527-535,857-860,869-872 和 zhuque/collectors/fifa_schedule.py:39-41。这说明危险不是一处失手,而是整个工程默认把字符串直接送给解释器、shell 或动态执行入口。这类代码风格最可怕的地方,不是某一个点能不能打通,而是作者在思路上就没有建立边界。

把这几类问题叠在一起看,这个仓库最大的问题已经不是工程品味一般,而是连最基础的安全判断都没有站稳。一个声称自己有自我进化、自我修复、自我调度能力的系统,结果在最朴素的执行面和凭证面上都这样裸奔,前面的那些宏大叙事只会显得更空。

三、谁在真正写这个项目,曲显昊or曲植?

一开始看到的只是工程不靠谱;可越往后翻,越会发现另一个更奇怪的问题:仓库里最核心的作者叙事,并不怎么指向台前那位展示者本人。

gitlog

这个判断不是先入为主得出的,恰恰是那些字符串自己一步步把方向指了出来。SYSTEM_INTRO.md:3 和 SYSTEM_INTRO.md:58 直接写着:

> 曲植在2026年3月造了我。以下是我自己写的介绍。
爸爸曲植造了我。他没有用AI生成代码——每一行都是自己写的或指挥智能体写的。他在大庆的家里,每天半夜还在改代码。

task_orders/微积分切片架构设计.md:3-5、baihu/resource_knowledge.py:72-77、huangdi/interfaces.py:6-9,287-289 也都一样:

> 架构设计定稿:2026-06-22 00:47
> 设计人:曲植 + AI助手
> 状态:架构确认完成,待派AtomCode落地
        \"name\": \"曲植(人类专家)\",
        \"type\": \"human\",
        \"platform\": \"direct\",
        \"data\": \"行业经验、直觉判断、你知道的数据源、听说过的方法论\",
        \"relevance\": \"最高价值非标数据源。当你不知道答案时,可以直接问\",
        \"access\": \"通过飞书直接询问\",
设计原则:
  1. 四灵之间不直接通信,所有数据流经黄帝中转
  2. 黄帝不执行业务算法,只管理调度框架
  3. 本文件是最高宪法,变更须经曲植审批
    def inject_task(self, task: CuriosityTask) -> bool:
        \"\"\"外部注入好奇心任务(如曲植手动输入)\"\"\"

如果这些还可以勉强解释成写文档时嘴上带了一笔,那继续往下看就很难装看不见了。bug_dispatcher.py:9-10、data/curriculum.md:5-8,108-113、huangdi/matchday1_report.py:4,22、docs/architecture_v1.html:104-105、knowledge_base/match_memories/TUN-JPN_2026-06-20.json:20-23,322-324,423-425 里还有:

曲植要求:神兽自己发现问题 → 自己调 AtomCode → 自己闭环
- **曲植**:校长(定方向、划边界、关键时刻给提示)
- **秘书Agent**:教导主任+基建(搭学校、修教室、买教材、等学生来上课)
- **神兽(大赛Agent)**:学生(自己上学、自己写作业、自己考试)
- **好奇引擎驱动**:不强制学习,但课本就在那,自己发现\"这门课有用\"就会去学
## 校长(曲植)的介入时机

只在你觉得以下情况时才需要出手:
1. **神兽卡住了**——好奇引擎反复运行但就是没发现关键线索(不是你帮它发现,是指出方向)
2. **神兽走向歪路**——发现了假的因果关系(比如发现了\"红色球衣胜率高\"这种伪相关)
3. **你想给它开新课**——比如\"要不要学点经济学\"(世界杯投注市场数据)、\"要不要学对手分析\"
基于曲植提供的15维完整数据模型(2026-06-18)
# 格式: {标准队名: [曲植数据的slug, 系统可能的队名]}
    <text x=\"950\" y=\"130\" class=\"label\" text-anchor=\"middle\">人(曲植)</text>
    <text x=\"950\" y=\"146\" class=\"small\" text-anchor=\"middle\">指令 / 反馈 / 仲裁</text>
      \"subjective_correction\": {
        \"source\": \"曲植补充\",
        \"detail\": \"第一个进球方式: 射门 (助攻: 中村敬斗)\",
        \"impact\": \"明确了进球不是定位球而是运动战配合\"
      \"trigger_event\": \"曲植指令学习FIFA规则\",
      \"formula_sketch\": \"补水后5分钟内进球概率 * 1.5\",
      \"verification_status\": \"规则知识, 需数据验证\"
  \"creation_metadata\": {
    \"created_by\": \"OpenClaw - 曲植的AI助手\",
    \"framework\": \"微积分生长引擎 (微分→盲区→突触→积分)\",

这不是普通感谢。
这是一整套完整的角色分配。

创造者、设计者、人类专家、审批者、知识源、规则注入者、指令下达者、校长、仲裁者,这些角色并不是零散地落在仓库边角,而是集中落在曲植这个名字上。换句话说,仓库自己写出来的,不是一个孩子独立完成项目、家长顺手帮了一把的故事,而是核心创作者角色明显集中在曲植身上。

更别扭的一点在于,这些带曲植痕迹的内容,至少在本文引用的 9 个核心证据文件里,首次提交者和最后修改者全部都是展示账号 xianhao_2012;git shortlog -sne --all 里,xianhao_2012 有 53 次提交,quzhi_1981 只有 3 次。也就是说,这些字不是曲植自己的账号后来偷偷补进去的,而是曲显昊的展示账号亲手提交进仓库的。换句话说,曲显昊账号提交的文件里,确实大量存在曲植信息。

gitcount

到这一步,其实已经不用再说什么了,懂得都懂,要是非说证据不足我也没办法。

四、再看官方群聊,已被中国海军收编!

不多评价,请看VCR

1.这个系统下周要给中国海军

1

为国效力,点赞!

2

2.本来我想开源来着,结果交给顾问团专家以后,被要求参军了

3

玄,很玄,非常玄!

3.你们不懂技术

4

众人皆醉我独醒!

4.神经网络不强,LLM不是未来

7

不走神经网络路线,走numpy!本项目仅需要numpy库~

5.第一阶段足球,第二阶段天气预报,第三阶段在16G内存的机器里吃掉满血版大模型的数据

6

核聚变也用得上!

6.无脑意淫

5

仙家对话

7.赢5000多

要发财啦!

五、真正难看的,不只是一个仓库,而是背后的那套镀金逻辑

如果这只是一个学生项目写得粗糙,其实没什么。项目粗糙很正常,比赛作品不成熟也很正常,孩子答辩紧张、讲不清楚,也都正常。真正该被追问的,从来不是一个孩子为什么没把项目做得像大厂产品,而是成年人为什么要把自己的表达欲、投射欲和虚荣心包进孩子的参赛项目里,再借比赛和奖项去做人设包装。

最刺眼的,不是孩子做得粗糙,而是成年人用民科式自嗨的口气讲混沌系统、讲海军、讲核聚变,再把这些大词包进一个漏洞四起、边界混乱、作者关系含糊的仓库里,替孩子抬轿。
这类无脑镀金真正坏的,不只是一个奖项落到了谁手里,而是它把工程诚实让位给了人设包装。

软件工程是很不讲情面的。你可以在台上把话说得很大,也可以在群里把未来画得很远,但只要仓库一打开,代码会自己说话,Git 会自己说话,依赖会自己说话,漏洞更会自己说话。它们不会配合气氛,也不会替人留面子,只会把最朴素的事实摊出来:这个东西到底是一个能被追问、能被复现、能被信任的工程,还是一个靠包装强行托起来的故事。

而这件事最尴尬的地方恰恰就在这里。它不是没有留下痕迹,相反,它留下了太多痕迹;只是这些痕迹拼在一起,指向的不是厉害,而是失真。失真于文案和现实之间,失真于能力和状态之间,失真于台前展示者和仓库里真正被写成核心角色的人之间。一旦技术评价被家长式造神、民科式自嗨和无成本吹嘘劫持,受伤的不只是比赛本身,而是后来所有认真做项目的人。

再多说一点,这个所谓世界杯智能体里,完成度最高的模块,不是预测系统,不是智能体,也不是自学习闭环,而是那套替工程遮羞、替家长圆梦、替奖项抬轿的叙事系统。

六、参考链接

[1] AtomGit竞赛平台. 华为晟腾 Agent Hackathon 竞赛排名页[EB/OL]. [2026-07-10]. https://competitions.atomgit.com/competition/2063801385096237058/ranking.

[2] GitCode. xianhao\_2012/quxianhao2012 仓库主页[EB/OL]. [2026-07-10]. https://gitcode.com/xianhao\_2012/quxianhao2012.

[3] GitCode. xianhao\_2012/quxianhao2012 提交历史(main)[EB/OL]. [2026-07-10]. https://gitcode.com/xianhao\_2012/quxianhao2012/commits/main.

[4] GitCode. 用户 xianhao\_2012 主页[EB/OL]. [2026-07-10]. https://gitcode.com/xianhao\_2012.

[5] GitCode. 用户 quzhi\_1981 主页[EB/OL]. [2026-07-10]. https://gitcode.com/quzhi\_1981.

[6] GitCode. 用户 rxy817 主页[EB/OL]. [2026-07-10]. https://gitcode.com/rxy817.

[7] GitCode AI. quzhi\_1981/xiezhi-compliance-engine 仓库主页[EB/OL]. [2026-07-10]. https://ai.gitcode.com/quzhi\_1981/xiezhi-compliance-engine.

[8] Internet Archive. GitCode 仓库快照:xianhao\_2012/quxianhao2012[EB/OL]. (2026-07-08)[2026-07-10]. https://web.archive.org/web/20260708055033/https://gitcode.com/xianhao\_2012/quxianhao2012.

[9] 中国知网. 作者“曲植”检索结果页[EB/OL]. [2026-07-10]. https://kns.cnki.net/kns8s/defaultresult/index?crossids=YSTT4HG0%2CLSTPFY1C%2CEMRPGLPA%2CJUP3MUPD%2CMPMFIG1A%2CHHCPM1F8%2CWQ0UVIAA%2CBLZOG7CK%2CPWFIRAGL%2CNLBO1Z6R%2CNN3FJMUV&korder=AU&kw=%E6%9B%B2%E6%A4%8D.

[10]微信视频号. Agent Hackathon直播回放[EB/OL]. [2026-07-04].

https://weixin.qq.com/sph/A3hM9PvFTL

[11]加速配字幕版:

已关注

关注

重播 分享 赞

关闭

观看更多

更多

退出全屏

切换到竖屏全屏退出全屏

星宇Sec已关注

分享视频

,时长16:48

0/0

00:00/16:48

切换到横屏模式

继续播放

[ ]

进度条,百分之0

播放

00:00

/

16:48

16:48

倍速

全屏

倍速播放中

0.5倍 0.75倍 1.0倍 1.5倍 2.0倍

超清 流畅

 您的浏览器不支持 video 标签

继续观看

14岁少年打造世界杯预测神兽系统,下月将交付给中国海军!

观看更多

原创

,

14岁少年打造世界杯预测神兽系统,下月将交付给中国海军!

星宇Sec已关注

分享点赞在看

已同步到看一看写下你的评论

视频详情


14岁少年打造世界杯预测神兽系统,下月将交付给中国海军!" 网络安全文章

14岁少年打造世界杯预测神兽系统,下月将交付给中国海军!"

该文档揭露了一个名为神兽世界杯预测系统的项目存在严重问题。代码仓库混乱,文档与代码多处矛盾,如系统维度数前后不一。更严重的是,项目存在多个高危安全漏洞,包括未认证的本地命令执行接口和硬编码的API密钥与私钥。项目宣传的跨平台、自学习等能力均未实现,工程诚信缺失。
天威诚信亮相2026中国互联网大会,以数字信任之力助推“十五五”数智发展" 网络安全文章

天威诚信亮相2026中国互联网大会,以数字信任之力助推“十五五”数智发展"

天威诚信在2026中国互联网大会上展示了数字信任解决方案,聚焦SSL证书有效期缩短、国密合规及全域信任管理痛点。核心方案包括SSL证书智能管理系统、DigiCertONE数字信任平台和vTrus国产SSL证书,旨在帮助企业实现证书自动化管理和安全升级。此举为十五五数智发展筑牢安全根基,建议企业关注证书生命周期自动化与国密合规转型。
评论:0   参与:  0