Low-Code Paradox in DevOps: Security and Governance Insights from Practitioners

以下是用通俗易懂的语言和富有创意的类比对该论文的解读，严格遵循作者所提出的发现与主张。

宏观图景：“快车道”与“安全网”

想象一家想要更快建造房屋的建筑公司。他们拥有两种工具：

1. DevOps（开发运维）：一支高度组织化、专业的工程师团队，他们无缝协作，快速完成房屋的建造、测试和交付。
2. 低代码平台（LCDPs）：一套类似“乐高积木”的构建套件。这些套件甚至让非专业建筑师（称为“公民开发者”）也能快速拼接墙壁和窗户，而无需亲手搅拌水泥或砌砖。

本文探讨的是，当你试图将这些乐高积木引入专业建筑工地时会发生什么。作者将这种现象称为“低代码悖论”。

悖论：乐高积木让建造过程变得更快、更简单（效率提升），但同时也会在墙壁中制造出新的、隐蔽的孔洞，供窃贼（黑客）潜入（安全风险）。

作者做了什么（研究方法）

研究人员并非凭空猜测，而是走访并与来自芬兰、西班牙和中国的12 位经验丰富的建筑经理和工程师（IT 专业人士）进行了交谈。这些人多年来一直同时使用专业方法和乐高积木。

他们询问了这些问题：“当你将这些快速的乐高积木与快速构建流程结合时，安全和规则方面会出现什么问题？”

他们倾听回答并寻找共同模式，就像侦探拼凑线索一样。

他们的发现（研究结果）

1. “双刃剑”

专家们一致认为，低代码是一把双刃剑。

• 好的一面：它自动化了枯燥的任务，帮助团队更快地构建应用程序。这就像拥有一只机械臂，能瞬间放置砖块。
• 坏的一面：由于这些套件连接了众多其他工具（如外部电源或水管），它们创造了更大的“攻击面”。这就好比为了让进入房屋更方便，你给房子加了一百扇新门和新窗；现在，小偷有一百个地方可以闯入。

2. “影子”问题

一个主要问题是影子 IT（Shadow IT）。这发生在员工使用这些乐高积木自行构建工具，却未告知 IT 安全团队时。

• 类比：想象建筑工地上的一名工人秘密用自制的锁搭建了一扇侧门，而主保安对此一无所知。保安以为房屋是安全的，但实际上有一扇未上锁的后门。论文指出，攻击者正越来越多地寻找这些未经授权的工具。

3. “SolarWinds"的警钟

研究人员提到了一个著名的真实世界黑客事件（SolarWinds），攻击者通过供应链潜入大型公司。

• 教训：即使乐高积木制造商声称“我们已更新安全”，这也可能不够。论文建议，仅仅拥有工具是不够的；你需要不断扫描整栋房屋寻找裂缝，而不仅仅是检查前门。

4. 人为因素

专家们指出，虽然这些工具有助于团队协作，但使用它们的人往往忽视了安全。

• 类比：这就像因为电钻容易握持而把它交给一个孩子。他们可以快速搭建一把椅子，但可能没意识到自己刚刚在煤气管道上钻了一个洞。论文表示，“网络卫生”（基本的安全习惯）是防止此类事故的最佳方式。

提出的解决方案：“整体框架”

作者不仅指出了问题，还构建了一个安全框架（见其图 2）来解决这些问题。他们提出了三大主要策略：

1. 自动化安全检查（左移）：
   不要等到房屋建成后才检查漏水，而是在拼接乐高积木的过程中就进行检查。使用自动化工具在应用程序完成之前就扫描安全漏洞。

2. 零信任（“永不信任，始终验证”原则）：
   想象一家高安全性的银行。即使你持有钥匙，守卫每次你穿过一扇门时都会检查你的身份证。论文建议将此原则应用于软件：验证每一个请求，即使是来自建筑物内部的请求，并仅授予人们所需的最小权限。

3. 适应性治理（规则手册）：
   既然任何人都可以用这些套件构建，公司就需要一本严格的规则手册。

   • 沙盒隔离：让人们在“沙盒”（一个安全、隔离的区域）中玩弄乐高积木，这样即使他们弄坏了什么，也不会导致整个公司崩溃。
   • 命名规范：确保所有人以相同的方式命名文件和文件夹，以免丢失或混淆。
   • 供应商审查：在购买新乐高套件之前，检查制造商是否安全，以及他们是否遵守公司的规则。

核心结论

论文总结道，低代码与 DevOps 是强大的组合，但它们需要文化上的转变。

你不能只是购买工具并寄希望于最好的结果。组织需要：

• 像对待传统编码一样严肃对待这些新工具。
• 接受你无法做到 100% 安全，但你可以做到具有韧性。
• 建立一种文化，让每个人都关心安全，而不仅仅是安全团队。

简而言之：速度固然重要，但如果你在奔跑时不锁门，你将失去一切。 论文认为，凭借正确的规则和以安全为先的思维，公司可以享受低代码的速度，而不会被黑客抢劫。