Musings

<div class="field field-name-field-lv2-subtitle field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">29 years writing for and editing ;login:</div></div></div><div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">October 2, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Musings</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/musings-1#Rik%20Farrow" title="Rik Farrow">Rik Farrow</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9552"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Today marks my last day as the editor of ;login:. The USENIX Board <a href="https://www.usenix.org/blog/2024-usenix-annual-meeting-report" target="_blank" title="Board decision to end ;login: (in final section)">has decided</a> that having a magazine is not on purpose for an organization that runs scientific conferences related to computer science. You can read the Board's full explanation in <a href="https://www.usenix.org/blog/2024-usenix-annual-meeting-report" target="_blank">the blog post</a> for the 2024 Open meeting. While I mostly agree with the Board's decision, there are other factors involved, not the least that at 75, it is time for me to step down. In this short article, I will share a little of my history with ;login: with you.</p> <p>In 1996, Ellie Young, then the Executive Director of USENIX, approached me during a USENIX conference. She asked me if I would like to be the editor of ;login:, and that she had also asked the editor of Unix Review magazine, Andrew Binstock. I was definitely interested, as I liked working with USENIX and was excited about being able to edit a technical Unix magazine with almost no advertising. I had worked with Unix World Magazine, where more than half the staff employed dealt with advertising, and 64% of the magazine's content was advertising, a not unusual amount.</p> <p>Rob Kolstad was the current editor, and he had no interest in giving up his position, even if he treated editing ;login: as a hobby. Rob continued being the editor until April of 2005 when he discovered he had no content for the June 2005 issue. The Board decided to let me edit ;login:, starting with that issue.</p> <p>I had written a proposal for editing ;login: in 1996, and when I changed to my :login: directory in 2005 and typed "vi proposal", there was my original proposal. I made some minor changes, emphasizing that I would focus on articles relating to conferences as a well of promoting conference attendance. The Board agreed. Young told me that part of my editor's duties included attending all conferences and workshops. That made sense to me if I was going to cover USENIX conferences, and getting to attend the conferences and many workshops with my expenses covered was exciting to me. My own work as a Unix and security instructor had been diminishing as Windows (actually hacking Windows) became more popular, and I thought I'd enjoy editing ;login:.</p> <p>And for the most part, I have enjoyed editing ;login:. There were parts I didn't like or found difficult to do, mainly running the collection of graduate students that summarized conference presentations and reading page proofs. In 2016, the Board decided to end the publication of summaries, as most presentations were now videoed. That simplified my editing task in one way—there's nothing quite like having over a dozen reluctant summary authors to deal with every issue—but made life more difficult in another. I now had to come up with more feature articles.</p> <p>I had high standards for articles that rested on two things. First, the topic of articles must be relevant to the USENIX community, and for articles based on conference papers, that part was relatively easy. The second thing was much more difficult: how to pick research that would be interesting to a broader set of people than just those who routinely attended the particular conference. I needed to do that for two reasons: I wanted to share interesting research beyond a conference's community and I needed to have hundreds, if not thousands, of people reading the published articles. As USENIX was not paying authors, their payment came in the form of the greater recognition for their research that a well-written article could bring. And, over time, I became very successful at this. Clem Cole, past Board president, told me that I was an analyst in that I had a real skill at picking interesting research. On a side note, it was common for me to pick the same papers for articles that would go on to win best paper awards—not always, but it seemed I had an additional ability to choose papers that award committees also liked.</p> <p>I am not sure what I will be doing in retirement. In a way, I was like Rob Kolstad, treating ;login: as an interesting (and paying) hobby: something that I liked to do and found extremely interesting. I wonder how well I will manage to keep up with computer science research going forward without the stimulus of having article authors to find. But I do remain curious about new research in all of the areas that USENIX conferences cover.</p> <p>I really appreciated getting to meet and work with the authors of articles and summaries, and attending USENIX conferences. I found the attendees friendly and helpful, and plan to continue to stay in touch with some of the thousands of people I met over the decades. I thank all of you for your assistance, for writing, and allowing me to edit ;login: for so many years. I also appreciated working with the USENIX staff, who made the process of producing print ;login: easy, as well as running conferences smoothly. I want to thank Steve Gilmartin, a poet, for copy editing ;login: when it was in print.</p> <p>Good bye for now...</p> <p>&nbsp;</p> <p>Rik Farrow</p> <p>&nbsp;</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9553"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/4LcQPyfKyjW6MW0MjRkRzYniZra_mXNzRWbvyh7AyOw/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9wcmludC1lZGl0aW9ucy5qcGc" width="1440" height="1081" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Stacks of the printed editions of ;login: that I either edited or wrote articles for.</div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a><p>Rik Farrow's website, including the long version of his bio: <a href="https://rikfarrow.com/about/">https://rikfarrow.com/about/</a></p> </div><div class="field-item even"><a class="anchor" name="reference-2"></a></div><div class="field-item odd"><a class="anchor" name="reference-3"></a></div><div class="field-item even"><a class="anchor" name="reference-4"></a></div><div class="field-item odd"><a class="anchor" name="reference-5"></a></div><div class="field-item even"><a class="anchor" name="reference-6"></a></div><div class="field-item odd"><a class="anchor" name="reference-7"></a></div><div class="field-item even"><a class="anchor" name="reference-8"></a></div></div></div></div></fieldset>

2025/10/1
阅读更多

Wafer-Scale AI Compute: A System Software Perspective

<div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">October 1, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Research</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Congjie%20He" title="Congjie He">Congjie He</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Yeqi%20Huang" title="Yeqi Huang">Yeqi Huang</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Pei%20Mu" title="Pei Mu">Pei Mu</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Mike%20Wang" title="Mike Wang">Mike Wang</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Ziming%20Miao" title="Ziming Miao">Ziming Miao</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Jilong%20Xue" title="Jilong Xue">Jilong Xue</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Lingxiao%20Ma" title="Lingxiao Ma">Lingxiao Ma</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Fan%20Yang" title="Fan Yang">Fan Yang</a>, <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#Luo%20Mai" title="Luo Mai">Luo Mai</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9527"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>As AI models grow larger and more complex, traditional computing architectures are hitting performance and efficiency limits. A new class of hardware, <strong>wafer-scale AI chips</strong>, pushes these boundaries by integrating hundreds of thousands of cores and massive on-chip memory onto a single wafer. Yet hardware alone is not enough: <strong>system software must evolve to fully harness its capabilities</strong>.</p> <p>This article examines how the pursuit of <strong>AI scaling laws</strong>&nbsp;has led to the emergence of wafer-scale systems. We introduce <strong>PLMR</strong>, a conceptual model that captures their key architectural traits, and explain why today's AI software stacks fall short in exploiting them. We argue that wafer-scale systems offer a promising path toward <strong>efficient scaling of test-time compute</strong>, mitigating the off-chip communication bottlenecks inherent in today’s multi-chip designs.</p> <p>We then present <strong>WaferLLM</strong>, a system that achieves <strong>sub-millisecond-per-token inference latency</strong>, demonstrating how wafer-scale integration can deliver tangible scaling efficiency. We conclude with directions for <strong>rethinking the AI system stack</strong>&nbsp;in the era of wafer-scale computing.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9528"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">AI scaling laws and the case for wafer-scale compute</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>AI scaling laws reveal a consistent pattern: larger models and more compute often yield predictable accuracy gains and emergent capabilities&nbsp;<a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-1">[1]</a>. These trends point toward a shared goal, pursuing extreme computational scale and efficiency, underpinned by the expectation that progress toward AGI will require increasingly powerful systems.</p> <p>The pursuit of scaling laws motivates the push toward larger AI chips. These chips integrate more cores and memory, with efficient on-chip communication to support intensive workloads. Larger integration improves efficiency by reducing costly off-chip communication, since more data can be stored and processed locally. This progression is evident in the adoption of chiplet and system-on-wafer technologies by AMD, NVIDIA, Google, and others, who continue to expand chip size across generations, as illustrated in Figure 1 <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-2">[2]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-3">[3]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-4">[4]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-5">[5]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-6">[6]</a>.&nbsp;</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9532"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/aaMozhZhvMnyt-3D1IoR-mOg9eq7jEv-ve5iZgvf_s0/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9sYXJnZXItY2hpcF8xXzAuanBn" width="1440" height="913" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 1: The trend toward larger and more complex chips [2][3][4][5][6]. This figure shows the progression from single-die to multi-die/chip by major vendors like NVIDIA, AMD, Google and others, who continue to expand chip size across generation. </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9533"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Recent advances in semiconductor technology have made the vision of ever-larger chips increasingly practical. Improvements in advanced packaging, finer process nodes, and more effective cooling have enabled designs that were previously infeasible. Taiwan Semiconductor Manufacturing Company (TSMC), for example, has reported strong demand for wafer-scale integration technologies <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-7">[7]</a>, which can scale chip sizes to a full wafer, often tens of times larger than conventional designs based on a single die (see Table 1).</p> <p>For AI workloads, the advantages are clear. A full wafer can integrate millions of cores and tens of gigabytes of SRAM, interconnected through a network-on-chip. This architecture offers compute and memory bandwidth far beyond what even the largest chips today can provide (see Table 1), while keeping data movement local to the wafer.</p> <p>Compared to conventional multi-chip systems, wafer-scale integration greatly reduces communication costs. Data transfer across the on-chip network is typically 10-100× more energy-efficient than board-level interconnects (see Table 1), enabling much tighter coupling of cores and memory. These efficiency gains have led organisations such as IEEE and TSMC to anticipate a coming wave of wafer-scale computers <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-7">[7]</a>. At the same time, AI companies, including Mxitral, Perplexity, Meta, and others, are beginning to explore wafer-scale systems as a platform for running advanced LLMs <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-8">[8]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-9">[9]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-10">[10]</a>.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-html-table paragraphs-item-html-table paragraphs-item-full paragraphs-item-9534"> <div class="content"> <div class="field field-name-field-table-contents field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><table> <tbody><tr align="center" valign="middle"> <th scope="col">&nbsp;</th> <th scope="col">System-on-Die</th> <th scope="col">System-on-Wafer</th> </tr> <tr align="center" valign="middle"> <th scope="row">Area</th> <td align="center" valign="middle">Typically 858 mm<sup>2</sup></td> <td align="center" valign="middle">Typically 73,062 mm<sup>2</sup></td> </tr> <tr align="center" valign="middle"> <th scope="row">#Transistors (TSMC n3)</th> <td align="center" valign="middle">1 trillion</td> <td align="center" valign="middle">~10s trillions</td> </tr> <tr align="center" valign="middle"> <th scope="row">Interconnect</th> <td align="center" valign="middle">PCB/RDL/SUB/WoW</td> <td align="center" valign="middle">Wafer</td> </tr> <tr align="center" valign="middle"> <th scope="row">Die-to-die efficiency</th> <td align="center" valign="middle">~10s pJ/bit</td> <td align="center" valign="middle">~0.1s pJ/bit</td> </tr> <tr align="center" valign="middle"> <th scope="row">Die-to-die bandwidth</th> <td align="center" valign="middle">~ 1-10s TB/s</td> <td align="center" valign="middle">~ 10 - 100s TB/s</td> </tr> <tr align="center" valign="middle"> <th scope="row">Memory Bandwidth</th> <td align="center" valign="middle">10s TB/s (shared via all-to-all)</td> <td align="center" valign="middle">10s PB/s (aggregated via mesh)</td> </tr> <tr align="center" valign="middle"> <th rowspan="3" scope="row">Off-chip memory</th> <td rowspan="3">10s - 100s GB</td> <td rowspan="3"> 10s TB&nbsp;via TSMC SoW in 2027 </td> </tr> <tr align="center" valign="middle"> </tr> <tr align="center" valign="middle"> </tr> </tbody></table></div></div></div><div class="field field-name-field-table-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Table 1: System-on-Die vs. System-on-Wafer (Estimated on TSMC N3 Process Node). For metrics crucial to AI inference, like memory and inter-core communication bandwidth, system-on-wafer is about 100 to 1000 times more powerful than system-on-die.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9535"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">How wafer-scale compute challenges software design</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>We want to understand how emerging wafer-scale computing challenges affect today's AI system software design. Consider a commodity wafer-scale system such as the Cerebras WSE-2 (see Figure 2 <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-11">[11]</a>). These chips integrate hundreds of thousands of cores, each equipped with local fast memory, compute logic optimised for floating-point arithmetic, and a router that connects to other cores through a network-on-chip (NoC).&nbsp;</p> <p>A key observation is that wafer-scale systems often expose their <strong>mesh-like interconnect</strong>&nbsp;to software developers (see Figure 2). Mesh interconnects are preferred because they simplify cooling and power delivery while offering cost-effective, near-linear communication scalability as core counts increase. A mesh topology also improves resilience against manufacturing defects. For example, Cerebras includes redundant links and cores across the wafer. When defective regions are detected, the hardware driver performs a <strong>hardware remapping process</strong>, reconfiguring the interconnect to bypass faulty areas and preserve a virtually intact two-dimensional mesh topology. This process effectively hides defects from developers, who can program the system as if it were built on an ideal, fully functional mesh network.</p> <p>Another key observation is that wafer-scale systems adopt a <strong>distributed, asynchronous programming model</strong>. As core counts reach into the hundreds of thousands, maintaining a shared-memory abstraction becomes impractical, and global synchronisation quickly dominates execution time. Instead, wafer-scale systems rely on <strong>asynchronous message passing</strong>&nbsp;between cores. Each core executes independently, and developers can control how computation, data access, and message transmission occur asynchronously when handling incoming messages. Developers are also responsible for preventing potential deadlocks. Further,&nbsp;developers also need to define <strong>software-controlled data placement</strong>, deciding where data resides across the wafer and how it streams from the host to the chip during execution.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9536"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/bLVyxkiKRQm4XfcnXXfolsFK04yAv1ZLT0HZFVHA0b8/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9vbi1jaGlwLXNjYWxpbmdfMS5qcGc" width="972" height="669" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 2: An example of a commodity wafer-scale AI system [9]. The wafer is composed of a massive array of cores, each with its own local memory, compute unit, and router. These cores are interconnected via a mesh network-on-chip, creating a highly parallel, distributed-memory architecture with unique software design challenges.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9537"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">PLMR: A conceptual model to capture architectural trait</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Programming a wafer-scale system demands careful attention to several key hardware architectural features; overlooking them can severely degrade software performance.&nbsp;We capture these in a conceptual device model, PLMR (pronounced "Plummer"), which identifies four characteristics that software developers must consider:</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9538"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/AvFRHkORF1WcHv_9zr2D8DG1LvulvaYKHTrnlEDNIHw/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9wbG1yXzEuanBn" width="1440" height="611" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 3: The PLMR model, which captures the key architectural traits of wafer-scale systems and outline the main challenges for software developers.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-callout paragraphs-item-callout paragraphs-item-full paragraphs-item-9539"> <div class="content"> <div class="field field-name-field-callout-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><ul> <li><strong>Massive Parallelism (P)</strong>: Leveraging the vast number of cores on a wafer requires sophisticated strategies for partitioning and replicating computation. Unlike traditional systems with tens or hundreds of GPUs, wafer-scale architectures may involve keeping millions of cores simultaneously active. This scale further demands careful scheduling to ensure that communication and computation are effectively overlapped across all cores.</li> <li><strong>Highly Non-uniform Memory Access Latency (L)</strong>: On a wafer-scale mesh, distance is a critical factor. When a core fetches data from a distant core's memory, the request must traverse many intermediate routers. In an N<sub>w</sub> × N<sub>h</sub> 2D mesh, the worst-case distance is N<sub>w</sub> + N<sub>h</sub> hops, which, for a million-core wafer, can amount to several thousand hops. In practice, accessing remote memory can be roughly 1000× slower than accessing a core's local memory. Minimising long-range communication is therefore essential for performance.</li> <li><strong>Constrained per-core Local Memory (M)</strong>: The large total on-chip memory of a wafer-scale system (tens of gigabytes) is, in fact, composed of many small fragments. Each core provides only a limited local memory, typically ranging from a few tens of kilobytes up to a few megabytes. This design choice reflects a tradeoff: smaller memories are faster and more energy-efficient, so wafer-scale architectures favour numerous small SRAM blocks over a few large ones. For software, the key implication is that all data, such as activations and weights, must be partitioned into chunks that fit within each core's local store.</li> <li><strong>Constrained Routing Resources (R)</strong>: With millions of cores communicating, the on-chip network (NoC) becomes a critical and limited resource. Each core’s router has hardware constraints on the number of distinct routes it can maintain. For instance, on the Cerebras WSE-2, a router can recognise only a 5-bit address in message headers, allowing direct hardware addressing of at most 32 destinations. Sending to more destinations requires relaying messages through intermediate cores, which incurs additional software overhead for header parsing and rewriting. To mitigate these costs, communication patterns should favour locality; each core should primarily exchange data with a fixed set of neighbours, while global synchronisation and communication should be minimised.</li> </ul> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9554"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>When designing efficient software for wafer-scale compute, <strong>PLMR can serve as a checklist: </strong>performance-critical AI kernel and parallelism strategy should be PLMR-compliant. Importantly, <strong>PLMR is not limited to wafer-scale chips; it</strong> <strong>reflects a broader architectural shift from unified memory to large-scale NUMA designs</strong>. Unified memory, typically implemented with crossbars or all-to-all interconnects, scales poorly because networking cost grows exponentially with the number of cores and memory units. By contrast, emerging interconnects such as 2D mesh, ND mesh, 2D torus, and 3D torus scale with linear networking cost, but <strong>shift the complexity of maintaining efficient parallel computation onto software</strong>.</p> <p>Software developers must now manage NUMA behaviour at scale, where memory access latency can differ substantially between nearby and distant cores. These programming challenges are already evident in non-wafer-scale architectures such as Tenstorrent and NVIDIA's upcoming Rubin and Blackwell chips, where stream processor (SM) interconnects expose NUMA properties to developers, as well as in AI clusters organised around mesh-based topologies (e.g., Google TPU Pods and Tenstorrent Galaxy).</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9540"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Limitations of today's AI software design approaches</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>This brings us to a critical question: <strong>Are our AI software design approaches ready for wafer-scale compute?</strong>&nbsp;To run an AI model on a distributed memory architecture, existing works generally have two choices: (i) abstract the distributed local memory in each core as a shared memory and directly access data placed in a remote core through NoC; and (ii) explicitly partition computation into distributed cores and use message passing to exchange necessary data. We analyse two types of representative systems: AI runtimes or DNN compilers for shared memory&nbsp;<span style="box-sizing: border-box; margin: 0px; padding: 0px;">architectures, such as GPUs (e.g., Ladder <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-12">[12]</a>); and compilers for distributed on-chip memory architectures (e.g., T10 <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-13">[13]</a> for GraphCore IPU).&nbsp;</span></p> <p><strong>Shared-memory AI systems.</strong> A shared-memory-based DNN compiler such as Ladder and others&nbsp;<a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-14">[14]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-15">[15]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-16">[16]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-12">[12]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-18">[18]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-19">[19]</a><a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-20">[20]</a> usually assumes a uniform memory access pattern within the underlying memory hierarchy, which often focuses primarily on partitioning computation, with less emphasis on optimising data partitioning. However, as we described previously, a wafer-scale chip is formed by interconnecting a massive number of smaller cores via a mesh-like NoC. If one uses a shared-memory-based DNN compiler to create a uniform memory abstraction for the wafer-scale chip's distributed on-chip memory, it will lead to severe long-distance and random communication between cores, and easily exceed the SRAM limits of a single core.&nbsp;</p> <p><strong>Distributed-memory AI systems.&nbsp;</strong>There are two main types of these methods: one is similar to T10 <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-13">[13]</a>, designed for AI accelerators with an on-chip crossbar, which ensures a constant latency of memory access to any other cores on the same chip. The other is similar to AI parallel computing systems, such as Megatron-LM <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-17">[17]</a>, which utilise tensor parallelism and pipeline parallelism, and are designed for high-performance clusters with full connectivity via NVLink, NVSwitch, and InfiniBand. However, crossbar and switch networks have limited scalability; an interconnection scale of millions would lead to severe cost overhead and cluster failure rates. The wafer-scale chip was designed with a mesh-like topology precisely for this reason. Therefore, existing work on distributed memory systems cannot be directly applied to wafer-scale chips either.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9542"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Harnessing wafer-scale compute for test-time scaling</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>The recent surge in interest in test-time scaling presents a compelling opportunity to demonstrate how wafer-scale computing can enable this emerging paradigm. The core idea of test-time scaling is simple: by allowing a Large Language Model (LLM) to "think longer", that is, to generate significantly more tokens than in prior settings, the model can achieve much higher accuracy and robustness. This has been demonstrated in recent systems such as GPT-5, DeepSeek-R1, Gemini, and Claude 4.5.</p> <p><strong>The demand for test-time scaling creates strong pressure for ultra-low-latency decoding at the per-user level.</strong> A longer reasoning process can easily consume tens of thousands of tokens, and with the rise of agentic AI, the requirement may extend to millions of tokens per user. To keep this "thinking" process interactive, completing tasks within seconds rather than minutes, the system must decode tokens at under one millisecond, ideally approaching the microsecond level. Conventional AI chip designs cannot meet this requirement: their decoding throughput is fundamentally limited by HBM bandwidth, which typically supports only hundreds of tokens per second per user, insufficient for test-time scaling.</p> <p><strong>Wafer-scale systems, by contrast, provide</strong> <strong>orders of magnitude higher memory bandwidth</strong>. For example, the Cerebras WSE-2 chip delivers about 20 PB/s of&nbsp;<strong>aggregate bandwidth</strong>, representing the total sum of local memory bandwidth of its massive number of cores. This total sum far exceeds that of HBM, which sacrifices overall bandwidth for a unified memory design.</p> <p>However, <strong>the advantage of high aggregate bandwidth does not come for free</strong>. The hardware relies on system software that must carefully coordinate asynchronous computation across all cores, using message passing to synchronise operations without deadlock, balance workloads, and avoid communication bottlenecks. Without such coordination, the system cannot fully realise the theoretical memory bandwidth that wafer-scale hardware promises.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9543"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Designing WaferLLM for efficient wafer-scale inference</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Motivated by the above observation, we began developing WaferLLM two years ago. The results are particularly exciting. By redesigning the LLM inference software stack, aligning performance-critical AI kernels with parallelism strategies, we demonstrate, for the first time, that per-user LLM inference latency can be reduced to below one millisecond using today's commodity wafer-scale technology. We present the full details of WaferLLM in our OSDI 2025 paper <a href="https://www.usenix.org/publications/loginonline/wafer-scale-ai-compute-system-software-perspective#reference-11">[11]</a>. In&nbsp;the following sections, we briefly highlight several key design principles of WaferLLM.</p> <p>At a high level, WaferLLM takes LLM checkpoints and applies new strategies to parallelise their execution across wafer cores. These strategies target two critical inference stages: prefill and decode (see Figure 4). The prefill stage involves loading the model weights, with its performance dominated by General Matrix-Matrix Multiplication (GEMM). The decode stage requires loading both the model weights and the KV-cache, where the performance-critical operation is General Matrix-Vector Multiplication (GEMV).</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9544"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/-pA9Sl4hppciadFuBQfJmOmLnkWoySyzWIoXmzVlM1Q/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9sbG0taW5mZXJlbmNlLXByb2Nlc3NfMS5qcGc" width="1440" height="912" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 4: The two key stages of LLM inference, Prefill and Decode. Effective test-time scaling depends on scaling LLM decoding performance for each user.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9545"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p><strong>Wafer-scale-friendly parallelism strategies.</strong> First, for parallelisation, WaferLLM partitions activation and weight matrices along two dimensions during prefill, and replicates while partitioning activation vectors during decode. This design aligns with the wafer’s massive parallelism and ensures compliance with the P and M requirements in PLMR.</p> <p>Second, WaferLLM avoids costly matrix and vector transpositions, which are common pitfalls in wafer-scale computing and violate the L in PLMR. Instead, it uses transpose-aware GEMM algorithms and pre-transposed parameter placement.<br> <br> <strong>Boosting the performance of key parallel compute operations.</strong> For GEMM and GEMV, WaferLLM introduces PLMR-compliant algorithms tailored to mesh interconnects, called MeshGEMM and MeshGEMV. These algorithms are explicitly designed to align with the constraints of the PLMR model and deliver highly efficient performance on wafer-scale systems.</p> <p>As shown in Figure 5(a), MeshGEMM addresses the Latency (L) and Routing (R) challenges by using cyclic shifting and interleaving to construct the shortest possible communication paths. Compared with state-of-the-art GEMM algorithms optimised for Clos or Torus topologies, MeshGEMM reduces communication overhead by 2-5× on mesh networks, leading to 1.3-2× end-to-end GEMM speedups.</p> <p>For MeshGEMV, illustrated in Figure 5(b), WaferLLM employs a K-tree Allreduce to minimise the length of critical communication paths. On mesh topologies, MeshGEMV reduces communication overhead by 1.5-6× compared with GPU-cluster GEMV algorithms, and achieves 2.5-3× faster performance.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9546"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/bJ3lPd3W6jJkuJ290y0qRtQKkht3-0SsvYPJk5STkhc/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy8yLWhvcC1jb21tdW5pY2F0aW9uXzEuanBn" width="1440" height="756" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 5(a): GEMM Communication Comparison on mesh network. MeshGEMM uses Cyclic-shifting and Interleave to reduce communication latency from O(N) to O(1) compared to standard algorithms.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9547"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/qxkzDZK3du7_gi_kBw29Agck7uG7FDcrPPDHW7oiBkc/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9rLXRyZWUtYWxscmVkdWNlXzEuanBn" width="1440" height="616" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 5(b): GEMV Communication Comparison on mesh network. MeshGEMV employs a K-tree Allreduce to shorten the critical communication path latency.</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9548"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Another key operation is KV cache management. For this, WaferLLM introduces a novel shift-based KV-cache management algorithm that incrementally redistributes cache entries across adjacent cores in parallel. This design aligns with the Constrained Local Memory (M) principle of PLMR, ensuring balanced memory utilisation and consistent workload distribution across the wafer. As a result, it extends the maximum inference length by several hundred times compared to baseline systems and eliminates out-of-memory errors.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9549"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Scaling efficiency: wafer-scale vs. multi-chip approaches</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>With WaferLLM, we are now able to fully utilise a wafer-scale chip. The next question is whether wafer-scale computing truly fulfils its promise of providing more efficient scaling than today’s approaches, which coordinate multiple chips interconnected by high-speed networks such as NVLink and InfiniBand.</p> <p>We evaluated WaferLLM on a real Cerebras WSE-2 wafer-scale chip (TSMC 7nm) against state-of-the-art GPU-based inference systems, including SGLang and vLLM, deployed on NVIDIA A100 GPUs (also TSMC 7nm) interconnected via NVLink and InfiniBand.</p> <p>As shown in Figure 6, when the number of GPUs increases from one to eight through tensor parallelism, decoding throughput rises from 78 to 260 tokens per second. While this improvement is substantial, it falls short of ideal 8× scaling, reflecting NVLink's communication overheads that affect <strong>decode latency</strong>, a key metric for test-time compute. Performance further declines when scaling beyond a single server: moving from 8 to 16 GPUs introduces InfiniBand overheads that reduce throughput.</p> <p>In comparison, <strong>WaferLLM</strong>&nbsp;achieves 2,700 tokens per second, corresponding to sub-millisecond latency per decoded token. This level of performance enables real-time AI agent applications that are currently difficult to support on conventional clusters.</p> <p>Beyond performance, we also examine whether wafer-scale systems can achieve <strong>efficient test-time scaling</strong>, higher performance without disproportionate energy costs. Normalising decoding throughput by power draw (A100 GPU vs. Cerebras WSE-2), WaferLLM shows an <strong>energy ratio&nbsp;</strong>of 0.92 compared to SGLang on a single A100 (values below one indicate higher efficiency for the A100). However, when scaling to 8 GPUs, the ratio exceeds one and reaches 2.22, indicating that wafer-scale systems become <strong>more energy-efficient</strong>&nbsp;as scale increases.</p> <p>It is worth noting that the wafer-scale results remain preliminary, as runtime, core, and on-chip interconnect efficiency are still being optimised. Continued improvements in the software stack are expected to enhance both performance and efficiency.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9550"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/wUTTexWVJBXn_TIA7nhfG6R3mGosLOCvnhozfy20H_0/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9yZXN1bHRfMS5qcGc" width="1440" height="425" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 6: Scaling efficiency comparison for wafer-scale and multi-GPU systems. For LlaMA3-8B decoding, the wafer-scale system (WSE-2) achieves 2,700 tokens/s, significantly outperforming an 8-GPU A100 server (260 tokens/s). The world-record results highlight the wafer-scale system's superior performance and its improved energy efficiency at scale, avoiding the communication bottlenecks of multi-chip setups.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9551"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Rethinking the full AI system stack for wafer-scale compute</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>WaferLLM has demonstrated the strong potential of wafer-scale AI systems. Yet, realising the full promise of wafer-scale computing requires rethinking the entire AI stack, from model architectures to software systems and hardware design.</p> <p><strong>Aligning AI model designs with wafer-scale compute.&nbsp;</strong>A first step is to adapt model architectures to the unique strengths of wafer-scale systems. Wafer-scale hardware offers massive parallelism and unprecedented on-chip bandwidth. This raises a critical question: should future model architectures and training algorithms be explicitly designed for wafer-scale platforms? For example, given a fixed parameter budget, should models become wider, with larger hidden dimensions, or deeper, with more layers? Addressing this requires careful study of how model structure interacts with bandwidth utilisation and parallelism at the wafer scale. Tailoring models to these characteristics could unlock significant gains in both performance and efficiency.</p> <p><strong>Advancing wafer-scale software capabilities.&nbsp;</strong>Wafer-scale's extreme parallelism and distributed memory architecture also call for rethinking system software. Traditional stacks, designed for off-chip scaling and relatively uniform memory access, may prove inadequate for this purpose. Managing distributed memory and scheduling fine-grained tasks across millions of cores introduces challenges that could require new memory management and parallel compute systems, runtimes, and schedulers. Even long-standing programming models such as MPI, originally created for clusters, may need to be revisited. A wafer-native distributed programming paradigm could simplify development, improve performance, and better exploit locality and parallelism inherent to wafer-scale hardware.&nbsp;</p> <p>Looking ahead, future wafer-scale AI computers will integrate even greater memory capacity, enabling large numbers of concurrent users to share the same machine. <strong>This raises a fundamental question: how should an operating system be designed to manage such massive systems?</strong> Unlike conventional designs, where memory and cores are organized in a unified shared space, a wafer-scale operating system must coordinate vastly larger pools of compute, memory, and I/O resources&nbsp;in a distributed and asynchronous manner—even though they reside on a single chip.&nbsp;This shift will transform core OS mechanisms for resource abstraction, concurrency, fairness, debugging, and beyond.</p> <p><strong>Designing more efficient wafer-scale hardware.&nbsp;</strong>Ultimately, there are opportunities for future hardware innovations that extend beyond today's mesh topologies. While mesh architectures offer strong simplicity in both manufacturing and programming, they are not always optimal for operations such as all-reduce communications, which are common in attention-based models. Can we design specialised NoC topologies that preserve scalability to millions of cores while accelerating such communication patterns? Exploring these directions may further amplify the efficiency and performance advantages of wafer-scale systems.</p> </div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a><p>[1] Wei, J., Tay, Y., Bommasani, R., Raffel, C., Zoph, B., Borgeaud, S., Yogatama, D., Bosma, M., Zhou, D., Metzler, D., Chi, E. H., Hashimoto, T., Vinyals, O., Liang, P., Dean, J., &amp; Fedus, W. "Emergent Abilities of Large Language Models," Transactions on Machine Learning Research (2022).</p> </div><div class="field-item even"><a class="anchor" name="reference-2"></a><p>[2] Andersch, M., Palmer, G., Krashinsky, R., Stam, N., Mehta, V., Brito, G., &amp; Ramaswamy, S. "NVIDIA Hopper Architecture In-Depth," NVIDIA Technical Blog, March 22, 2022. <a href="https://developer.nvidia.com/blog/nvidia-hopper-architecture-in-depth/">https://developer.nvidia.com/blog/nvidia-hopper-architecture-in-depth/</a>.</p> </div><div class="field-item odd"><a class="anchor" name="reference-3"></a><p>[3] NVIDIA. "NVIDIA Blackwell Architecture — The Engine Behind AI Factories," 2025. <a href="https://www.nvidia.com/en-us/data-center/technologies/blackwell-architecture/">https://www.nvidia.com/en-us/data-center/technologies/blackwell-architec...</a>.</p> </div><div class="field-item even"><a class="anchor" name="reference-4"></a><p>[4] NVIDIA Writers. "GTC 2025 -- Announcements and Live Updates," NVIDIA Blog, March 25, 2025. <a href="https://blogs.nvidia.com/blog/nvidia-keynote-at-gtc-2025-ai-news-live-updates/">https://blogs.nvidia.com/blog/nvidia-keynote-at-gtc-2025-ai-news-live-up...</a>.</p> </div><div class="field-item odd"><a class="anchor" name="reference-5"></a><p>[5] AMD. AMD Instinct™ MI325X Accelerators. <a href="https://www.amd.com/en/products/accelerators/instinct/mi300/mi325x.html">https://www.amd.com/en/products/accelerators/instinct/mi300/mi325x.html</a>.</p> </div><div class="field-item even"><a class="anchor" name="reference-6"></a><p>[6] Jouppi, N., Kurian, G., Li, S., Ma, P., Nagarajan, R., Nai, L., Patil, N., Subramanian, S., Swing, A., Towles, B., et al. "Tpu v4: An optically reconfigurable supercomputer for machine learning with hardware support for embeddings," Proceedings of the 50th annual international symposium on computer architecture (2023), pp. 1–14.</p> </div><div class="field-item odd"><a class="anchor" name="reference-7"></a><p>[7] LaPedus, M. "TSMC bets big on advanced packaging," 2023. <a href="https://spectrum.ieee.org/tsmc-advanced-packaging">https://spectrum.ieee.org/tsmc-advanced-packaging</a>.</p> </div><div class="field-item even"><a class="anchor" name="reference-8"></a><p>[8] Cerebras Systems. "Cerebras Powers Perplexity Sonar with Industry's Fastest AI Inference," 2025. <a href="https://www.cerebras.ai/press-release/cerebras-powers-perplexity-sonar-with-industrys-fastest-ai-inference">https://www.cerebras.ai/press-release/cerebras-powers-perplexity-sonar-w...</a>.</p> </div><div class="field-item odd"><a class="anchor" name="reference-9"></a><p>[9] Wang, J. "Cerebras Brings Instant Inference to Mistral Le Chat," 2025. <a href="https://cerebras.ai/blog/mistral-le-chat">https://cerebras.ai/blog/mistral-le-chat</a>.</p> </div><div class="field-item even"><a class="anchor" name="reference-10"></a><p>[10] Cerebras Systems. "Cerebras and G42 Break Ground on Condor Galaxy 3, an 8 exaFLOPs AI Supercomputer," 2024. <a href="https://cerebras.ai/press-release/cerebras-g42-announce-condor-galaxy-3">https://cerebras.ai/press-release/cerebras-g42-announce-condor-galaxy-3</a>.</p> </div><div class="field-item odd"><a class="anchor" name="reference-11"></a><p>[11] He, C., Huang, Y., Mu, P., Miao, Z., Xue, J., Ma, L., Yang, F., &amp; Mai, L. "WaferLLM: Large Language Model Inference at Wafer Scale," 19th USENIX Symposium on Operating Systems Design and Implementation (OSDI 25) (2025), pp. 257–273.</p> </div><div class="field-item even"><a class="anchor" name="reference-12"></a><p>[12] Wang, L., Ma, L., Cao, S., Zhang, Q., Xue, J., Shi, Y., Zheng, N., Miao, Z., Yang, F., Cao, T., et al. "Ladder: Enabling Efficient Low-Precision Deep Learning Computing through Hardware-aware Tensor Transformation," 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24) (2024), pp. 307–323.</p> </div><div class="field-item odd"><a class="anchor" name="reference-13"></a><p>[13] Liu, Y., Xue, Y., Cheng, Y., Ma, L., Miao, Z., Xue, J., &amp; Huang, J. "Scaling Deep Learning Computation over the Inter-Core Connected Intelligence Processor with T10," Proceedings of the ACM SIGOPS 30th Symposium on Operating Systems Principles (2024), pp. 505–521.</p> </div><div class="field-item even"><a class="anchor" name="reference-14"></a><p>[14] Chen, T., et al. "TVM: An Automated End-to-End Optimization Stack for Deep Learning," SSP 2018 (2018).</p> </div><div class="field-item odd"><a class="anchor" name="reference-15"></a><p>[15] Ma, L., Xie, Z., Yang, Z., Xue, J., Miao, Y., Cui, W., Hu, W., Yang, F., Zhang, L., &amp; Zhou, L. "Rammer: Enabling Holistic Deep Learning Compiler Optimizations with rTasks," 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20) (2020), pp. 881–897.</p> </div><div class="field-item even"><a class="anchor" name="reference-16"></a><p>[16] Shi, Y., Yang, Z., Xue, J., Ma, L., Xia, Y., Miao, Z., Guo, Y., Yang, F., &amp; Zhou, L. "Welder: Scheduling Deep Learning Memory Access via Tile-graph," 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23) (2023), pp. 701–718.</p> </div><div class="field-item odd"><a class="anchor" name="reference-17"></a><p>[17] Narayanan, D., Shoeybi, M., Casper, J., LeGresley, P., Patwary, M., Korthikanti, V., Vainbrand, D., Kashinkunti, P., Bernauer, J., Catanzaro, B., Phanishayee, A., &amp; Zaharia, M. "Efficient large-scale language model training on GPU clusters using Megatron-LM," Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (2021), pp. 1–15.</p> </div><div class="field-item even"><a class="anchor" name="reference-18"></a><p>[18] Zhao, Y., et al. "Ansor: A Compiler Stack for Auto-Tuning Tensor Programs," IEEE Transactions on Software Engineering (2020).</p> </div><div class="field-item odd"><a class="anchor" name="reference-19"></a><p>[19] Zheng, S., Liang, Y., Wang, S., Chen, R., &amp; Sheng, K. "FlexTensor: An Automatic Schedule Exploration and Optimization Framework for Tensor Computation on Heterogeneous System," Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems (2020), pp. 859–873.</p> </div><div class="field-item even"><a class="anchor" name="reference-20"></a><p>[20] Zhu, H., Wu, R., Diao, Y., Ke, S., Li, H., Zhang, C., Xue, J., Ma, L., Xia, Y., Cui, W., Yang, F., Yang, M., Zhou, L., Cidon, A., &amp; Pekhimenko, G. "ROLLER: Fast and Efficient Tensor Compilation for Deep Learning," 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22) (2022), pp. 233–248.</p> </div><div class="field-item odd"><a class="anchor" name="reference-21"></a></div><div class="field-item even"><a class="anchor" name="reference-22"></a></div><div class="field-item odd"><a class="anchor" name="reference-23"></a></div><div class="field-item even"><a class="anchor" name="reference-24"></a></div><div class="field-item odd"><a class="anchor" name="reference-25"></a></div><div class="field-item even"><a class="anchor" name="reference-26"></a></div><div class="field-item odd"><a class="anchor" name="reference-27"></a></div><div class="field-item even"><a class="anchor" name="reference-28"></a></div><div class="field-item odd"><a class="anchor" name="reference-29"></a></div><div class="field-item even"><a class="anchor" name="reference-30"></a></div><div class="field-item odd"><a class="anchor" name="reference-31"></a></div><div class="field-item even"><a class="anchor" name="reference-32"></a></div><div class="field-item odd"><a class="anchor" name="reference-33"></a></div><div class="field-item even"><a class="anchor" name="reference-34"></a></div><div class="field-item odd"><a class="anchor" name="reference-35"></a></div><div class="field-item even"><a class="anchor" name="reference-36"></a></div><div class="field-item odd"><a class="anchor" name="reference-37"></a></div><div class="field-item even"><a class="anchor" name="reference-38"></a></div><div class="field-item odd"><a class="anchor" name="reference-39"></a></div><div class="field-item even"><a class="anchor" name="reference-40"></a></div><div class="field-item odd"><a class="anchor" name="reference-41"></a></div><div class="field-item even"><a class="anchor" name="reference-42"></a></div><div class="field-item odd"><a class="anchor" name="reference-43"></a></div><div class="field-item even"><a class="anchor" name="reference-44"></a></div><div class="field-item odd"><a class="anchor" name="reference-45"></a></div><div class="field-item even"><a class="anchor" name="reference-46"></a></div><div class="field-item odd"><a class="anchor" name="reference-47"></a></div><div class="field-item even"><a class="anchor" name="reference-48"></a></div><div class="field-item odd"><a class="anchor" name="reference-49"></a></div><div class="field-item even"><a class="anchor" name="reference-50"></a></div><div class="field-item odd"><a class="anchor" name="reference-51"></a></div><div class="field-item even"><a class="anchor" name="reference-52"></a></div><div class="field-item odd"><a class="anchor" name="reference-53"></a></div><div class="field-item even"><a class="anchor" name="reference-54"></a></div><div class="field-item odd"><a class="anchor" name="reference-55"></a></div><div class="field-item even"><a class="anchor" name="reference-56"></a></div><div class="field-item odd"><a class="anchor" name="reference-57"></a></div><div class="field-item even"><a class="anchor" name="reference-58"></a></div><div class="field-item odd"><a class="anchor" name="reference-59"></a></div><div class="field-item even"><a class="anchor" name="reference-60"></a></div><div class="field-item odd"><a class="anchor" name="reference-61"></a></div><div class="field-item even"><a class="anchor" name="reference-62"></a></div><div class="field-item odd"><a class="anchor" name="reference-63"></a></div><div class="field-item even"><a class="anchor" name="reference-64"></a></div><div class="field-item odd"><a class="anchor" name="reference-65"></a></div><div class="field-item even"><a class="anchor" name="reference-66"></a></div><div class="field-item odd"><a class="anchor" name="reference-67"></a></div><div class="field-item even"><a class="anchor" name="reference-68"></a></div><div class="field-item odd"><a class="anchor" name="reference-69"></a></div><div class="field-item even"><a class="anchor" name="reference-70"></a></div><div class="field-item odd"><a class="anchor" name="reference-71"></a></div><div class="field-item even"><a class="anchor" name="reference-72"></a></div><div class="field-item odd"><a class="anchor" name="reference-73"></a></div><div class="field-item even"><a class="anchor" name="reference-74"></a></div><div class="field-item odd"><a class="anchor" name="reference-75"></a></div><div class="field-item even"><a class="anchor" name="reference-76"></a></div><div class="field-item odd"><a class="anchor" name="reference-77"></a></div><div class="field-item even"><a class="anchor" name="reference-78"></a></div><div class="field-item odd"><a class="anchor" name="reference-79"></a></div><div class="field-item even"><a class="anchor" name="reference-80"></a></div><div class="field-item odd"><a class="anchor" name="reference-81"></a></div><div class="field-item even"><a class="anchor" name="reference-82"></a></div><div class="field-item odd"><a class="anchor" name="reference-83"></a></div></div></div></div></fieldset>

2025/9/30
阅读更多

Musings on LLMs

<div class="field field-name-field-lv2-subtitle field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Why Do LLMs Use So Much Energy?</div></div></div><div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">September 29, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Opinion</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/musings-llms#Rik%20Farrow" title="Rik Farrow">Rik Farrow</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9521"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>With all the hype about Large Language Models (LLMs), I've been wondering about several things. No, I am not worried about General AI taking over the world, like some people. Instead I've been trying to get a handle on why devices used for training LLMs are so expensive, and why training and operating a LLM requires so much energy.</p> <p>here are some posts and articles about the energy used when creating GPT4. One article [1], based on leaked data, suggests that GPT-4 was trained using 25 thousand NVIDIA A100 GPUs for 90-100 days. NVIDIA sells HGX servers that can hold eight A100 each and use 6.5 kilowatts to operate under maximum load. As a guestimate, the author used the number of servers (3,125) times 6.5 times 24 times 90 to come up with a whopping 43 gigawatts of electricity. That's 43 thousand megawatts, and as the price of a megawatt varies based on location, time of day, I just went with $50/mw, so training GPT-4 likely cost &nbsp;over two million dollars just in electricity alone. The article's author came up with a range that starts where I do but ends around 60 thousand megawatts. &nbsp;For comparison, it requires 854 megawatts to<a href="https://www.compareforexbrokers.com/us/bitcoin-mining/" target="_blank"> 'mine' one Bitcoin in July of 2025.</a></p> <p>Just for fun, I decided to compare the GPT-4 estimates to ten hour flights, roughly Seattle to London, in the fuel-efficient Boeing 787-9. The 787-9 burns about 5400 liters of fuel per hour, so approximately 54,000 liters of fuel for each trans-Atlantic flight [3]. Each liter of fuel has about the same amount of energy as 10 kilowatts of electricity, so each flight uses the equivalent of 540,000 kilowatts, or 540 megawatts. Another way of visualizing this is that one of the three nuclear reactors in Arizona can produce almost this much electricity in one hour.&nbsp;</p> <p>Think about that for a minute. With carbon dioxide levels soaring to the point that some parts of the globe will become deadly within decades, flying across the ocean seems a bit irresponsible to me these days. Then compare that 540 megawatts to 43,000 megawatts possibly used to train GPT-4 — that's over 80 trans-Atlantic flights, using my lower energy figure. And GPT-4 is an older model with fewer parameters.</p> <p>I think that puts training a LLM into a different sort of perspective.<br> &nbsp;</p> <p>Training LLMs actually occurs in several phases:<br> &nbsp;</p> <ul> <li>Pre-training, the part that is the most energy intense, where the LLM is fed a somewhat curated copy of the Internet, often including pirated copies of books; this produces what's called a foundation or base model.</li> <li>Training, where LLMs are provided with example questions and answers as a method of improving the way LLMs will respond to queries.</li> <li>Fine-tuning, the process of adjusting LLMs, similar to training but more focused.</li> </ul> <p>You can read more about this process in an article written by Chinese researchers [3]. The folks at Shanghai AI Laboratory shared their experience with training and deploying an LLM at NSDI'24.</p> <p>Once an LLM has been prepared, it is ready to be used in a process called inference. The amount of energy used at this point per query is small, but using a popular model, like those of OpenAI, adds up when people are making millions of queries per day. One analysis [4] suggests that inquiries made using ChatGPT use only .3 watt per query, a lot less than others had suggested, at 3 watts per query. But that provides a range of 600,000 watts to 6 megawatts per day for using just one LLM for inference for two million queries.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9522"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Burning Energy</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>That brings me to my second question: why so much energy and why do people want to use NVIDIA GPUs? I first did some digging into why NVIDIA GPUs are so popular and what is special about them.</p> <p>The NVIDIA A100 could be found online for $30,000 a piece, based on my searches in the fall of 2023. The newer GPU, the H100, costs about as much, and is 1.6 to 6 times faster than the A10 [5]. Each GPU actually is a large chip, made by Taiwan Semiconductor Manufacturing Company (TSMC) for NVIDIA tightly coupled with HBM3 memory. HBM3 memory consists of vertically stacked layers of RAM providing wider transfers of memory than ordinary DRAM.</p> <p>You might think that other companies would have already copied the manufacturing of these chips, but you'd be wrong because these chips are unusual. Instead of just the usual collection of highly parallel but simple pipelined processing units typically found in a GPU, these chips have up to 80 GBs of their own memory on each A100 board and boast up to 1,555 GBs/second in access speed. The size of memory and speed of access is significant, as LLMs are immensely large, with sizes in the trillions of parameters, and each step in processing a token during pre-training means executing floating point multiplies and additions on all of these parameters.</p> <p>If an LLM is advertised as having 1 trillion parameters, and uses 20 billion input tokens during training, that's 10**12 * 2*10**10, or 2*10**22 sets of floating point operations during pretraining. During his 2025 FAST'25 keynote [6], Seelam of IBM cloud uses a slightly larger value, showing in his slides that pre-training is six times the total number of tokens times parameters.</p> <p>Ideally, all of the parallel pipelines provided by each NVIDIA GPU would remain busy constantly, but the reality is quite different. A model's parameters are not going to fit into a single HBM3 on a GPU, but must be distributed among multiple GPUs. This is also done for performance reasons. &nbsp;NVIDIA has its own networking interconnect, allowing the exchange of data between GPUs at 600 GBs/second, about one third the maximum memory rate. But model parameters cannot be neatly distributed in memory, even for one GPU.</p> <p>The A100 has been specifically designed to work well with tensor processing. Tensors are like multidimensional arrays, and are key to performance during pre-training of LLMs, and the A100 can perform 156 to 312 teraflops using 32 bit floating point values.</p> <p>When I began writing this article, the A100 and GPT-4 were new; today, it's the H100 and GPT-5. Ignoring GPT-5 for now, we can compare the A100 to the H100, both from NVIDIA. Based on an article that itself is based on performance testing by MosaicML, a company that is a managed LLM training and inference service, the H100 is 1.6 to 6 times faster than the A100. There are two big reasons for that.</p> <p>First are changes in how memory gets transferred to GPU compute cores. The H100 uses HBM3 that supports faster copying of memory to the cores than DRAM. The Tensor Memory Accelerator is a new part of the NVIDIA Hopper architecture that handles memory management, freeing up GPU cores to do what they are best at: math.</p> <p>The second are improvements in floating point and integer calculations. One of the things that surprised me while researching this article was the use of eight bit floating point (FP8). Any eight bit value can have no more than 256 values, and given that earlier LLMs were using 32 bit floating point, with 2^^32 possible values, it didn't seem to me that FP8 would provide enough resolution. I asked Karl Koscher of NVIDIA why they didn't just use eight bit integers, and he said it's because FP8 has a greater range and that's what's important.</p> <p>But the H100 has the same problem as any other GPU when it comes to tensor operations. Tensors are multidimensional arrays. When a single dimensional array gets stored, programmers want to access each value one after the other, in order, for fastest access leading to faster processing. Tensors represent multidimensional arrays as single dimensional arrays with offsets (strides) for accessing each row, so accessing parameters during any use of an LLM means having to jump around in memory&nbsp;<em><strong>all of the time</strong></em>, making memory access slower than reading consecutive values.</p> <p>The sharding of parameters across GPUs is also an issue. Perhaps the LLM has a *small* number of parameters, just 20 billion, that could theoretically fit into the 80 gigabytes of HBM3 memory. But for performance reasons, people typically use multiple GPUs, so the parameters must be distributed. While eight NVIDIA GPUs will fit in one HGX server, multiple servers, connected using networking, may be in use. All of this slows down processing from peak speeds.</p> <p>I like to compare the sharding of parameters to the way supercomputers used to predict weather work, as I find it easier to visualize. Weather prediction algorithms split up the earth's atmosphere into 1.5 to 2 kilometer segments with several layers. If supercomputers had a single, shared pool of memory, you might imagine that the parameters for all segments would be stored in order. However, these segments are part of the 3D space representing earth's atmosphere and cannot be stored as if they were a one-dimensional array. Worse yet, this data is sharded across thousands of pools of memory.</p> <p>While processing parameters for one group of segments, that data might fit into one pool of memory. But what happens at the borders of this group of segments? That data gets stored in other pools and must be communicated across pools.</p> <p>For LLMs, the problem is even worse, as there are many more dimensions to the tensors, and parameters will be based on parameters in other tensors, meaning data must be copied between GPUs, and even between GPU servers. All this conspires to make using LLMs slower, and more energy expensive, than they might ideally be.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9523"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">LLMs and Parameters</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>LLM base models have gotten much larger. The leap in abilities from GPT-3 to GPT-4 suggested to AI experts that models trained on more data, with more parameters, worked better. Companies have now trained models with over a terabyte of parameters. The amount of training data has not grown as fast because once you have scraped the internet and copied libraries full of books, you're faced with the limit on the amount of training data. Having better training data is actually more important, and filtering training data turns out to be a very important task. You may want to watch the FAST'25 keynote by Seetharami Seelam [6] where he describes the training phases for a foundation model using IBM's Vela architecture.</p> <p>NVIDIA has been supporting parallel processing using the CUDA libraries since 2007. The most popular libraries for working with ML all support CUDA, and I think this alone is a huge advantage currently for NVIDIA, and owners of NVIDIA GPUs. It's been estimated that the markup on an A100 is 100 times the cost of making them, and that is unlikely to change for years, until other chip manufacturers can build similar hardware <em><strong>and</strong></em>&nbsp;come up with equally efficient software libraries for ML.</p> <p>CUDA libraries aren't just device drivers for communicating with NVIDIA GPUs. They are also very clever compilers that manage the arrangement of parameters in memory. CUDA has been in development for decades, meaning that NVIDIA has those decades of experience in software that best arranges parameters for LLMs and other AI software.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9524"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Software</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Riley Eller, a friend and fellow security geek, started prodding me to look deeper into ML in 2023. He did this by being excited about ML, using it in his latest startup, and then pointing me in the direction of online tutorials by Andrej Karpathy, who worked for Tesla on their vision recognition systems as well as being a founder of OpenAI.</p> <p>Karpathy has produced a number of fast-paced videos with examples you can build yourself—for the most part. When I began watching these, I found myself pausing the video often, trying to understand what he just did. Or why he did something. Still, I found it fascinating to watch him build two models in his second tutorial that input a list of first names and use that to predict whether a collection of characters might be a first name. For example, 'ellie' would have a result of 100%, while his own name with an 'x' after it, would be totally unlikely [7].</p> <p>Riley, being the smart guy that he is, actually first pointed me to a later video where Karpathy uses the collection of all the text in Shakespear's plays as the input tokens, about one million words. He then builds a General Purpose Transformer (GPT) and starts training it, then tuning it to reduce its loss. Eventually, he produces a model that outputs lines of text somewhat like a Shakespear play in style. Less trained versions could only produce random characters, so watching this process, and the tuning required, was enlightening to say the least.</p> <p>Watching Karpathy only informed me about how little I knew about ML. I found myself annoyed at terms he mentioned, or the uses of variable names like x, y, w, or logits that seemed arbitrary to me. Then I started reading books about ML, and learned that these were not arbitrary at all.</p> <p>I started with something I thought would be simple and quick: <em>Machine Learning in One Hundred Pages</em> by Andriy Burkov. I had read the first chapter, found his writing to be clear and concise, and bought the book. The second chapter briefly covers the math he would be using throughout the rest of the book. While I have used math over my career, suddenly the calculus course I took fifty years ago took on new importance, as did statistics.</p> <p>Burkov, as well as other ML researchers and physicists, use math as a language. Math is very concise as well as precise. &nbsp;I could understand enough of the math to barely get the points Burkov makes later in the book. &nbsp;Which, by the way, is 136 pages long. The book's name was a marketing trick, writes Burkov. And his book ends with just a couple of pages relating to the technique that makes LLMs possible: transformers. I also read other online sources about the Python libraries used in ML.</p> <p>I wondered why in the world people would use Python for compute-heavy tasks found in ML. There are a couple of answers, one being the conciseness of Python and its support for classes. The other is PyTorch, a library written in C++ that includes the tensor class with methods implemented in C++, meaning that compute-heavy operations are done here. So while Karpathy's tutorials use Python, they all are calling C++ routines which may in turn call into CUDA if you have NVIDIA devices. If you want to understand more about this, I suggest reading the first half of the notes about PyTorch in Eric Young's blog entry about getting started with contributing to PyTorch [8]. You might also want to look at <a href="https://github.com/karpathy/llm.c/discussions/677" target="_blank">llm.c</a>, a project started by Karpathy for recreating GPT-2 using only C.</p> <p>I kept watching Karpathy's videos, and worked with the Jupyter notebooks he uses in his tutorials. As I kept at it, I began to learn how machine learning works in LLMs. I had been upset when I learned that weights were initialized to random values, but Karpathy explains why this works, and why some other choices like starting weights set to zero wouldn't work.</p> <p>The parameters in LLMs are the weights and biases for each 'neuron' in a model. Hyperparameters are used when designing and pretuning an LLM, for example, the dimensions used in each layer, the number of hidden layers, or how much the gradient between neurons should be used to adjust the weights during backpropagation.</p> <p>Models mainly learn through the process of backpropagation, where the current prediction for the next token is matched against the actual next token, representing the 'loss'. The loss, actually the negative log of the probability of having matched correctly, is used to calculate the gradient, and the gradient is used to adjust weights moving backwards, up through the model, to the input layer. At this point, it's even easier for me to understand why the process of training LLMs is so energy intensive: every parameter gets changed with each step.</p> <p>You probably remember the big leap in performance, when OpenAI released GPT-4: from 175 billion parameters in GPT-3 to 1.8 trillion parameters in GPT-4. At the time, it appeared that increasing the number of parameters increased the ability of the LLM to create useful output. Increasing the number of parameters by a factor of 10 did make a difference, but so did other changes in the LLM, like having a Mixture of Experts architecture for use during inference. But, I believe, the increase in size and complexity is a huge part of the drive to building enormous data centers for enormous LLMs. Gundlach et al [11] have theorized that 'meeker' LLMs are the true future, not large ones.</p> <p>VIDIA gets to take advantage of this movement, as they will be able to sell more of their costly GPUs. On September 22, 2025, NVIDIA announced it will invest $100 billion in building data centers for OpenAI in exchange for OpenAI equity, an enormous bet in the technology. And many people are worried about how AI will upend the job market, both replacing entry-level jobs as well as some much more lucrative positions.</p> <p>Perhaps, just perhaps, things are not quite as rosy as OpenAI, Anthropic, and others think they are. I found research, where two groups of senior programmers wrote code, one group using AI while the other didn't, expecting that the AI-using groups would work faster: instead they didn't. It took the group using AI 20% longer to perform similar tasks, probably because they had to first understand and then correct code produced by something other than themselves [9].</p> <p>LLMs predict the next output token, whether for a marketing blurb or code, based on having been trained on as much data as can be found online. In some instances, using advanced AIs has proven tremendously helpful, for example, when searching for new molecules for drugs or superconductors. Those AIs were trained specifically for those applications. LLMs work by predicting the next output token, including some amount of context (previous tokens) in the query. These LLMs are not going to be making new discoveries in chemistry, as they predict tokens, that is characters, based on their training input.</p> <p>And let's consider biological models, instead of AIs. Scientists have completely mapped a fruit fly's brain with 139,255 neurons, and around 15.1 million weighted edges [parameters] when represented as a graph. With this, a fruit fly's brain supports complex motor control while walking or in flight, courtship behaviour, involved decision making, flexible associative memory, spatial learning and complex multisensory navigation [10].</p> <p>Or how about the human brain, with about 12 trillion synapses—parameters. Just like an LLM, training a human brain takes enormous effort, especially with the low bandwidth of reading and the spoken word. Still, at 20 watts TDP, many humans can outperform LLMs requiring megawatts of power, even if a lot more slowly. I think the future is going to be very interesting indeed, but I am not expecting General AI anytime soon, barring advances in fusion technology to power them at the very least.</p> </div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a><p>[1] Kasper Groes Albin Ludvigsen, The carbon Footprint of GPT-4: <a href="https://towardsdatascience.com/the-carbon-footprint-of-gpt-4-d6c676eb21ae">https://towardsdatascience.com/the-carbon-footprint-of-gpt-4-d6c676eb21ae</a></p> </div><div class="field-item even"><a class="anchor" name="reference-2"></a><p>[2] Fuel Efficiency of Modern Aircraft <a href="https://www.smh.com.au/traveller/reviews-and-advice/how-fuel-efficient-are-modern-commercial-aircraft-compared-with-cars-20190718-h1gc84.html">https://www.smh.com.au/traveller/reviews-and-advice/how-fuel-efficient-a...</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-3"></a><p>[3] Qinghao Hu, Peng Sun, Tianwei Zhang, Understanding the Workload Characteristics of Large Language Model Development: <a href="https://www.usenix.org/publications/loginonline/understanding-workload-characteristics-large-language-model-development">https://www.usenix.org/publications/loginonline/understanding-workload-c...</a></p> </div><div class="field-item even"><a class="anchor" name="reference-4"></a><p>[4] Josh You, How much energy does ChatGPT use? <a href="https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use">https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-5"></a><p>[5] Gcore, NVIDIA GPUs: H 100 vs. A100 comparison: <a href="https://gcore.com/blog/NVIDIA-h100-a100">https://gcore.com/blog/NVIDIA-h100-a100</a></p> </div><div class="field-item even"><a class="anchor" name="reference-6"></a><p>[6] Seetharami R. Seelam, Insights Gained from Delivering Two Generations of AI Supercomputers and Storage Solutions in IBM Cloud: <a href="https://www.usenix.org/system/files/fast25_slides-seelam-keynote.pdf">https://www.usenix.org/system/files/fast25_slides-seelam-keynote.pdf</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-7"></a><p>[7] Andrej Karpathy, Neural Networks: Zero to Hero: <a href="https://github.com/karpathy/nn-zero-to-hero?tab=readme-ov-file">https://github.com/karpathy/nn-zero-to-hero?tab=readme-ov-file</a></p> </div><div class="field-item even"><a class="anchor" name="reference-8"></a><p>[8] Eric Yang, PyTorch internals blog entry on contributing to PyTorch: <a href="https://blog.ezyang.com/2019/05/pytorch-internals">https://blog.ezyang.com/2019/05/pytorch-internals</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-9"></a><p>[9] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity: <a href="https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/">https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/</a></p> </div><div class="field-item even"><a class="anchor" name="reference-10"></a><p>[10] Schlegel, P., Yin, Y., Bates, A.S. et al. Whole-brain annotation and multi-connectome cell typing of Drosophila. Nature 634, 139–152 (2024). <a href="https://doi.org/10.1038/s41586-024-07686-5">https://doi.org/10.1038/s41586-024-07686-5</a> or <a href="https://www.nature.com/articles/s41586-024-07686-5">https://www.nature.com/articles/s41586-024-07686-5</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-11"></a><p>[11] Hans Gundlach, Jayson Lynch, Neil Thompson, Meek Models Shall Inherit the Earth, TAIG ICML 2025: <a href="https://arxiv.org/abs/2507.07931">https://arxiv.org/abs/2507.07931</a></p> </div><div class="field-item even"><a class="anchor" name="reference-12"></a></div><div class="field-item odd"><a class="anchor" name="reference-13"></a></div><div class="field-item even"><a class="anchor" name="reference-14"></a></div><div class="field-item odd"><a class="anchor" name="reference-15"></a></div><div class="field-item even"><a class="anchor" name="reference-16"></a></div></div></div></div></fieldset>

2025/9/28
阅读更多

Design Tradeoffs at the Edge

<div class="field field-name-field-lv2-subtitle field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Lessons from Operating a Large-Scale Reverse Proxy</div></div></div><div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">September 18, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Deployed System</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/lessons-operating-large-scale-reverse-proxy#Mitendra%20Kumar%20Mahto" title="Mitendra Kumar Mahto">Mitendra Kumar Mahto</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9502"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Introduction</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>A reverse proxy is a critical infrastructure component in any large-scale distributed system. You’ll find it at the edge as a TLS terminator, inside CDNs as a caching proxy, as an API gateway, as a load balancer, and as the front line for DDoS mitigation. As Internet services have grown in scale and complexity, the reverse proxy, alongside the rest of the traffic stack, has become increasingly central to reliability, performance, and security.</p> <p>There are mature reverse proxy and load balancer implementations that handle these problems at scale. But the Internet keeps evolving: scale increases, use cases shift, architectures change, and threat models expand. Reverse proxies and load balancers operate at multiple layers of the OSI stack. While layers 3–4 are critical, this article focuses on<strong> Layer 7 (application-level) load balancing</strong>, where application-specific behavior, fast-moving architecture patterns, and business-critical data intersect. Being in the application layer means this tier absorbs rapid ecosystem changes, protocols, client behaviors, and security/compliance expectations, which makes building and operating the reverse-proxy tier at scale a persistent challenge.</p> <p>Drawing on more than eight years in the proxy space, including six years leading LinkedIn’s traffic team, I worked with a group of engineers responsible for operating and stabilizing a large-scale reverse proxy stack that handled millions of requests per second. Together, we managed critical outages, rewrote large parts of the surrounding ecosystem, and developed the practices that kept the system reliable. This article reflects the lessons we learned as a team from those experiences, the tradeoffs we faced, and the principles that helped us make the proxy tier both fast and resilient.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9503"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">A Typical Reverse Proxy Workflow</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>At a high level, a reverse proxy performs the following:</p> <ol> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Connection management</b><br> The proxy is the first point of contact for clients. It establishes connections, terminates TLS, manages timeouts, validates certificates, and decides when to reuse connections.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">HTTP processing</b><br> Once a connection is established, the proxy parses the request, validates semantics, inspects for malicious patterns, extracts key information for policy and business decisions, and, if the request is valid, forwards it to backend services. This is also where protocol validation and many DDoS mitigations occur.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Authentication and authorization</b><br> Many resources are not public. The proxy often needs to determine whether the request is from a valid user or application and whether it has the right permissions to read, write, or update the targeted resource. The proxy typically enforces decisions, while policies and rules are sourced from dedicated services. This is a common point where the proxy must call external systems.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Service discovery</b><br> After a request is deemed valid and serviceable, the proxy must forward it to an appropriate backend host. In modern microservice architectures, instances are constantly changing due to deployments, autoscaling, and failures. The proxy needs a mechanism to discover services and hosts and to track their health and capabilities.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Load balancing</b><br> Knowing which service to target isn’t enough; the proxy must choose a specific healthy instance. For efficiency and reliability, load should be distributed across many backends. Load balancing is closely tied to discovery but has its own challenges and techniques.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Response Processing</b><br> Once the backend server responds, the proxy inspects the response for sensitive information and compliance requirements before forwarding it to the client. This is also where application-level security checks occur, such as stripping disallowed headers or cookies and adding headers like Cross-Origin Resource Sharing (CORS) or Content-Security-Policy (CSP).</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Operations, observability, and monitoring</b><br> As the Internet-facing tier, the proxy sees both legitimate and adversarial traffic. Unlike internal systems, where observability patterns are standardized, this tier often needs more specialized visibility. Without it, you risk dropping good traffic or letting harmful traffic bring down critical systems.</p> </li> </ol> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9504"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Connection Management: Cost, Reuse, and Protocol Realities</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Connections are central to how proxies operate. Modern infrastructure can handle millions of them, but resources are never unlimited. Each connection consumes memory, file descriptors, and kernel bookkeeping. Establishing a secure connection adds even more cost, with TLS handshakes using far more CPU than the requests they carry. Reusing connections helps spread out this cost, but it brings its own challenges. Striking the right balance between efficiency and risk is essential.</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Challenges in Practice</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>The first tradeoff is connection reuse</strong>. Keeping connections open reduces handshake overhead and improves latency, but it also creates opportunities for misuse. A client holding many idle sessions can later flood the system with requests at very low cost. Each of those requests may fan out across backends, multiplying the impact. Closing connections too aggressively adds churn; keeping them too long increases exposure.</p> <p><strong>Restarts are another recurring challenge</strong>. Proxies restart for deployments, configuration changes, and kernel upgrades. Each restart triggers a wave of reconnects. With many clients, this can cause a sudden spike in traffic—a retry storm—that overwhelms the system. Adding jitter, or random delays to reconnect attempts, spreads traffic over time and reduces the risk of overload.</p> <p><strong>Hardware realities complicate scaling</strong>. Adding more cores improves capacity, but a 64-core machine does not deliver 64 times the throughput. Limits such as Non-Uniform Memory Access (NUMA) boundaries, cache behavior, and uneven socket distribution mean that one core can become saturated while others remain underused. This makes the real bottleneck hard to detect—overall CPU charts may show headroom even as a single busy core throttles performance. Vertical scaling is useful, but to fully benefit from it often requires refining code paths or even changing parts of the underlying architecture.</p> <p><strong>And then there’s protocol diversity.</strong> HTTP/1.1 often creates short-lived connections, leading to churn. WebSockets stay open, reducing setup cost but holding resources for long periods. HTTP/2 and HTTP/3 multiplex many streams over one connection, improving efficiency but making each connection loss more disruptive. Protocol choice directly changes both cost and failure modes.</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">What We Learned the Hard Way</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Client-side timeouts are crucial</strong>. Too short, and connections churn unnecessarily; too long, and graceful restarts become difficult. Proxies typically provide multiple knobs to tune this behavior. For example, HAProxy includes settings like t<strong>imeout http-request</strong>,&nbsp;<b id="docs-internal-guid-3fa26b36-7fff-408d-e5bf-bb9c6d878e85">timeout http-request, timeout http-keep-alive, timeout client-hs, and timeout tunnel</b>. The right values depend on traffic and client behavior, but they must always be chosen deliberately to balance efficiency with stability</p> <p><strong>Don't overlook simple limits</strong>. Many of the most painful outages were caused by simple things, like running out of <strong>file descriptors</strong>. Once that ceiling was reached, new connections could not be formed even though everything else in the system was healthy. In practice, setting a higher limit with tools like <strong>ulimit</strong> proved to be one of the simplest and most effective safeguards against avoidable failures.</p> <p><strong>Vertical scaling has its own traps</strong>. Adding more cores doesn’t guarantee linear gains, and defaults rarely scale cleanly. The only safe approach is to measure, identify where the bottleneck really lies, and adjust settings based on evidence rather than assumptions. In one case, we ended up disabling the <a href="https://docs.trafficserver.apache.org/en/8.1.x/appendices/command-line/traffic_server.en.html#cmdoption-traffic_server-f">free_list</a> setting in Apache Traffic Server to make it work reliably on a 64-core machine, even though the feature was originally meant to improve performance.</p> <p><strong>TLS is a performance trade-off</strong>.&nbsp; Stronger ciphers increase CPU cost, weaker ones increase risk. Elliptic Curve Cryptography (ECC) offered a good balance, strong security with less overhead than RSA, but ciphers must still be monitored and retired as they age.</p> <p><strong>Don’t force one configuration to handle every workload</strong>. Short-lived API traffic behaves very differently from long-lived connections like messaging or video uploads, and trying to tune both in a single stack only adds complexity. Creating separate stacks for these profiles made the settings cleaner, the tuning more effective, and day-to-day operations much easier.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9505"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">HTTP Parsing and Handling: Overhead in the Details</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Layer 7 reverse proxies gain their strength from a deep understanding of HTTP. With that knowledge, they can route based on paths, enforce rate limits, authenticate users, block abuse, cache content, and compress responses. Developers often take advantage of this flexibility, and in the short term it works—systems appear simpler, state is reduced, and the user experience improves. But parsing HTTP at the edge is rarely straightforward. Browsers and user agents interpret the protocol differently, backend servers have their own assumptions, and the proxy must reconcile them all. When interpretations diverge, requests may be dropped or handled inconsistently. At scale, these small mismatches grow into outages or vulnerabilities, and attackers are usually the first to notice.</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Challenges in Practice</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Oversized URLs are a common challenge</strong>. Oversized URLs became a recurring issue in our partner-facing APIs. Batch operations let thousands of campaigns or profiles be fetched in a single call, and additional parameters to customize the result ballooned URLs to tens of kilobytes beyond proxy defaults. Raising limits kept them working but at a steep cost—higher parsing overhead, more memory use, and lower efficiency. What started as a convenience ended up complicating capacity planning and load balancing.</p> <p><strong>Cookies introduce similar problems</strong>. By embedding state in the browser, developers offload complexity from their servers. But cookies spread quickly—between domains, across teams, and even into logs. They leak information, bypass security checks, and present wildly inconsistent behavior across client libraries. Worse, once developers treat cookies as harmless key-value stores, they start using them as caches for sensitive data, creating risks that are difficult to contain.</p> <p><strong>Headers also become a source of trouble</strong>. User-Agent strings look like reliable signals until a regex parser chokes on a crafted input. The X-Forwarded-For header is trusted for hop validation, yet trivial to spoof. In both cases, assumptions about ‘routine’ inputs open easy paths for attackers..</p> <p><strong>Even when security is the goal, business needs can erode it</strong>. Sites often require authentication, yet want visibility in search engines (SEO). To accommodate crawlers, access checks are relaxed based on weak identifiers like a “Googlebot” header. Inevitably, attackers adopt the same identifiers, and the proxy ends up maintaining complex, brittle bot-detection logic to recover from the shortcut.</p> <p>All of these issues stem from a familiar set of assumptions:</p> <ol> <li>This is for internal use only, no one else will use/abuse it.</li> <li>Following the spec is enough, so guardrails aren’t necessary</li> <li>A little extra parsing cost is fine if it makes the client’s job easier.</li> </ol> <p>At scale, none of these assumptions hold, and design shortcuts turn into systemic risks</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">What We Learned the Hard Way</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Never trust input</strong>. Be fanatically defensive and sanitize everything. We learned that even a bad HTTP version string like <strong>0.5</strong>, which isn’t valid, could trigger crashes in parts of the stack. Trusting a header to mark “safe” upstreams once allowed apps in Azure to be misclassified as internal requests. Failing to reset fields like <strong>X-Forwarded-For</strong> or <strong>UUIDs</strong> let bogus values pollute logs and break correlation. The lesson was clear: always reset request metadata at the edge, and only pass through what the backend explicitly needs. If cookies influence policy, encode them consistently, check for tampering, and cross-validate with other signals. Routine fields often become the easiest vectors to exploit.</p> <p><strong>Fix outliers, don’t excuse them</strong>. Some of the most expensive problems came not from the general workload but from a handful of services with unusual patterns. Some APIs that embedded entire queries in GET requests created URLs hundreds of kilobytes long. For a while, we raised limits to keep them working, but that only increased memory pressure and parsing cost. Eventually we forced a redesign, and while it was painful for the product team, it cut the proxy’s footprint significantly. Raw GraphQL queries posed a similar challenge: easy for developers, but dangerous for the proxy tier. Replacing them with vetted query IDs preserved the flexibility and removed the risk of unbounded input. Long-running requests were another case. We shifted them to return a queryable ID immediately, with results fetched through a separate call. That redesign limited how long connections stayed open and freed capacity for other traffic. In each case, redesigning the outlier service gave the whole fleet a more stable baseline, while global exceptions only made things worse.</p> <p><strong>Headers and cookies aren’t just harmful; they’re costly.</strong> At scale, parsing and updating them consumed a large share of CPU. Every rewrite or adjustment added overhead. We learned to parse once, reuse results, and update only when absolutely necessary. In practice, header and cookie handling turned out to be one of the most expensive operations in the proxy. The risks were real too. A bad User-Agent regex once caused stack overflows under crafted input. Cookie quirks between iOS and Android WebViews created login loops that only appeared under load. Over time, we stopped treating headers and cookies as routine fields. We began treating them as costly and fragile, something to minimize, cache, or strip whenever possible.</p> <p><strong>Keep the stack current</strong>. HTTP may look stable, but the protocol and its implementations keep evolving. Staying current was not just maintenance—it was a defensive measure. Several major vulnerabilities only became visible after updates, and we avoided them simply by keeping our stack up to date. Examples included the HTTP/2 Rapid Reset Attack, the HTTP/2 Resource Loop, and the HTTP/2 Continuation Flood. In each case, running a current version closed the door on exploits before they became incidents.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9506"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Authentication, Authorization and policy verification: Fast, Safe, Available</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>At the edge, the proxy is often the first to decide whether a request should be allowed. That means verifying both identity (authentication) and permissions (authorization) before traffic ever touches the backend. The work sounds simple, but it mixes cryptography, external dependencies, and real-time checks, which makes it one of the more fragile stages in request handling. The proxy must enforce policy reliably, yet remain fast enough not to slow the rest of the system.</p> <p dir="ltr">&nbsp;</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Challenges in Practice</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Latency shows up first</strong>. Every call to validate a token or fetch a policy adds a round-trip. At low volume that cost is hidden, but at scale even a few milliseconds accumulate into a noticeable slowdown.&nbsp;</p> <p><strong>Performance is a constant balancing act</strong>. Stronger cryptography improves security but also raises CPU cost. The goal is always the same—more protection, but without overwhelming the proxy.</p> <p><strong>Availability adds a third dimension</strong>. Authentication and policy verification usually depend on external services. When those systems slow down or fail, strict enforcement at the edge can end up dropping valid requests and making the user experience miserable</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">What We Learned the Hard Way</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Be defensive with external data</strong>. Even trusted sources can send bad inputs due to bugs or misunderstandings. A single <a data-file-id="57444" href="https://www.usenix.org/system/files/srecon22emea_slides_palino_0.pdf">misplaced comma </a>in a policy response once brought the site down for several minutes. External services make it easy to update policies on the fly, but not every setting needs that flexibility. We moved less frequently changing items, such as trusted IPs and cookie definitions, into configuration and shipped them with the artifact. This reduced runtime corruption risks and improved performance by removing unnecessary dependencies</p> <p><strong>Reduce dependency on external calls</strong>. A sub-millisecond lookup in Redis or Couchbase looks cheap in isolation, but in a proxy it rarely is. Event-loop architectures don’t mix well with synchronous external calls. In Apache Traffic Server, for example, calls often advance only in <a href="https://docs.trafficserver.apache.org/en/9.0.x/developer-guide/api/functions/TSContSchedule.en.html">5 ms steps</a>. A few sequential lookups that each “took 1 ms” in a benchmark routinely turned into more than 20 ms of added latency. At low scale this was invisible, but at millions of requests per second the penalty was crippling.</p> <p>We learned to eliminate per-request lookups wherever possible. Stateless JSON Web Token (JWT) with short lifetimes gave predictable validation without round-trips.&nbsp;</p> <p><strong>Design for partial failure</strong>. External services will fail, sometimes briefly and sometimes for hours, and systems that enforced strict checks turned those outages into full lockouts. Instead of failing completely, we learned to build brownout modes that allowed the system to operate in a degraded but usable state. If a token couldn’t be renewed because the validation service was down, we granted a short grace period. That small risk gave downstream systems time to recover without disrupting every user session. For critical paths like SSO, we built alternate workflows and break-glass options so that operations could keep the system moving while dependencies were fixed. Availability wasn’t about avoiding failure; it was about continuing to function safely when failure was inevitable.</p> <p><strong>Separate tiers when goals diverge</strong>. Policy often grows complicated because we try to handle too many cases in one place to save operational cost. In practice, that leads to sprawling allowlists, denylists, and endless if/else conditions. The more complex the logic, the more often it breaks in unexpected ways. We learned that it was easier to keep tiers clean when their goals and policies were different. Each tier could evolve independently without being burdened by rules meant for another. For example, corporate traffic was pulled into its own workflow rather than mixed with general production, and ad traffic was given its own stack entirely because its goals and constraints were unique.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9507"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Service Discovery and Load Balancing: Change as the Constant</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>A proxy’s work doesn’t end when it accepts a request. It ends when that request reaches the right backend. With today’s dynamic services, that isn’t simple. Hosts scale up and down constantly, new ones appear in deployments, and old ones vanish or get stuck mid-flight. The proxy has to reshuffle its view in near real time, all while keeping the client experience seamless. Doing this well means more than just picking “any” host; it means finding a healthy one quickly, distributing load fairly, and avoiding overload. The real challenge is balancing accuracy with efficiency, tracking a moving fleet without burning more resources on bookkeeping than on serving users.</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Challenges in Practice</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Discovery is never perfect</strong>. Push-based updates converge quickly but bind the proxy tightly to the control plane. Polling approaches like DNS are looser but inevitably slower. No matter the method, the view of the fleet always lags reality. External systems can fail, add random delays, or drift out of sync, and the proxy has to make routing decisions in that uncertainty.</p> <p><strong>Health checks help but carry their own risks</strong>. Aggressive checks can create health-check storms, consuming capacity and ejecting healthy hosts. Relaxed checks leave broken hosts in rotation too long. Passive signals from real traffic are valuable, but only if there’s enough volume to separate noise from signal. The proxy is always balancing between too much probing and too little.</p> <p><strong>Not all hosts are equal</strong>. Some are just warming up, with caches still cold or JITs not yet settled. Others may be partially failing, serving some requests but dropping others. Treating all hosts as identical leads to overload or poor client experience. New hosts especially are prone to cold-start floods if traffic isn’t ramped in carefully.</p> <p><strong>Balancing traffic fairly is harder than it looks</strong>. Hashing reduces churn but still reshuffles keys when the ring changes. Algorithms like round robin or least connections behave differently depending on workload and topology. Even the “simplest” choices require tuning, because what looks balanced on paper can feel very unbalanced in production.</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">What We Learned the Hard Way</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Discovery is eventually consistent, embrace it with fallbacks</strong>. Service discovery and DNS always lag reality, and both fail more often than we expect. During a long DNS outage, the system kept running because the <a href="https://docs.trafficserver.apache.org/en/9.0.x/admin-guide/files/records.config.en.html?highlight=dns%20cache#proxy-config-http-cache-max-stale-age">serve-from-stale-cache</a> setting was configured for 24 hours, far longer than the typical few-second to one-hour TTLs. Passive health checks based on real traffic, with quarantine support, often helped catch bad hosts faster than discovery systems. Layered fallbacks through service discovery, DNS, and DNS from stale cache proved invaluable more times than we anticipated. For prolonged outages, we added event-loop–based health checks to detect when quarantined hosts had recovered, reducing reliance on external discovery and avoiding unnecessary noise.</p> <p><strong>There is no one off issue</strong>. Problems that looked random and disappeared after a restart often turned out to be discrepancies in topology or service discovery once we had enough logging and monitoring in place. Service discovery is noisy by design, with hosts constantly changing and errors surfacing everywhere, and it rarely provides enough traces to debug directly. The fix was to add richer but less noisy signals at the proxy layer. Metrics like the number of quarantined hosts, connection errors, total weights, and host counts helped us identify repeating patterns that once looked like isolated failures and turn them into actionable fixes.</p> <p><strong>Not all errors are equal</strong>. A connection refusal tells a different story than an HTTP 500 or a latency spike. Treating them the same blurred the real signals and left bad hosts in rotation far too long. Once we separated connection errors from latency or HTTP errors, outlier detection became far more reliable. For connection errors we used a rule of three consecutive failures, while for latency we looked for spikes within a recent time window, usually five minutes. Errors had to be weighted differently and signals decayed quickly so the system could adapt without overcorrecting.</p> <p><strong>Server-side feedback is critical</strong>. Proxies don’t talk to each other and each only sees a local view. When one proxy sees a backend handling less traffic, it tries to send more, but so do all the others, and the server ends up overwhelmed. Server feedback was the only way to correct this imbalance and adjust traffic in real time. Slow start made the need even clearer. Backends often needed time to populate caches or warm up JIT compilers, and the process wasn’t deterministic. Without feedback, clients had no way to know how much weight to assign upfront. With it, we could plan gradually and let servers ramp up safely.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9508"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Operations, Observability, and Monitoring: Seeing What Matters</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Running a large-scale proxy depends on observability. At the edge, it is not optional, it is survival. Unlike application services, proxies rarely look at full request bodies. What matters are the signals around them: metadata, control-plane events, and backend health.</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">Challenges in Practice</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>The first challenge is knowing what to watch</strong>. Connection metrics such as accepts, handshakes, and reuse rates tell us whether the proxy itself is stable. Request metadata such as methods, paths, header sizes, and retries helps separate normal traffic from abuse. Identity signals like token outcomes and TTL distributions reveal the health of authentication. Source data such as ASN, geography, or IP reputation often highlight abuse long before other systems see it. On the backend side, host counts, healthy ratios, error classes, and latency distributions expose whether load balancing is keeping up. And for debugging policy, nothing is more valuable than being able to answer why a request went to a specific backend.</p> <p><strong>Scale makes all of this harder.</strong> At millions of QPS (Query Per Second), full tracing is not realistic and raw logs will overwhelm both storage and operators. Sampling carefully, attaching lightweight request IDs, and recording structured policy decisions normally gives us enough visibility without drowning in data.</p> <p><strong>Observability only matters if it drives action</strong>. Service Level Objectives (SLOs) on tail latency, error budgets, and handshake success focused attention on what really impacted users. Runbooks give operators clear steps, such as how to drain connections, quarantine hosts, or switch discovery fallbacks under pressure. Even simple anomaly detectors, like spikes in header size or cookie counts, often catch incidents faster than complex pipelines.</p> <h3 dir="ltr"><b id="docs-internal-guid-0e21c261-7fff-ab98-cdd6-f77ca9aa4e31">What We Learned the Hard Way</b></h3> <p dir="ltr"><!--%3Cmeta%20charset%3D%22UTF-8%22%20%2F%3E--></p> <p><strong>Absence of success is also an error signal</strong>. A dip in 2xx traffic often appeared before 5xx errors spiked, especially during network issues with data centers or CDNs. By watching both successes and failures, we caught problems earlier instead of waiting for visible errors.</p> <p><strong>Aggregates hide real failures</strong>. System-wide averages looked fine even when a single host, data center, or route was failing badly. In one case, a single misbehaving host skewed performance for a large subset of users while global metrics stayed green. Fast drill-downs by host, route, or policy made it possible to see and fix these problems quickly.</p> <p><strong>Truth at scale is approximate</strong>. Backends constantly joined and left the fleet, making single snapshots misleading. A system could look “healthy” at one moment and degraded the next. We learned to rely on trends such as healthy vs. total host counts, quarantine rates, and effective traffic weights, which gave a more accurate and stable view of fleet health.</p> <p><strong>Rely on tools, but stay fluent in the basics</strong>. Rich metrics and searchable logs let us investigate subtle failures and novel attacks, turning vague suspicions into actionable findings. But when the observability stack itself failed, simple commands like <strong>grep </strong>and <strong>awk </strong>against raw logs were often the only way to see what was really happening. Keeping that muscle memory turned out to be just as important as building advanced tooling.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9509"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Conclusion</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Operating a reverse proxy at scale is demanding, and the complexity only increases without clear, reliable principles to guide design and operations.</p> <h3><strong>Operating Principles</strong></h3> <p><strong>Favor simplicity</strong>. Choose straightforward mechanisms with predictable failure modes over complex algorithms that may collapse under stress.</p> <p><strong>Decouple layers</strong>. Keep control and data paths loosely coupled so that discovery or control-plane failures do not block request serving.</p> <p><strong>Make tradeoffs visible</strong>. Document and communicate the performance and security costs of every policy or feature enforced at the proxy.</p> <p><strong>Design for failure</strong>. Anticipate brownout modes, degraded operation, and partial dependency failures. Build backpressure and graceful fallback paths into the system.</p> <p><strong>Build for evolution</strong>. Expect protocols, ciphers, and client behaviors to change. Schedule regular hygiene tasks such as cipher deprecation, limit reviews, and configuration audits.</p> </div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a><p>Todd Palino, Commas Save Lives (SRECon22): <a href="https://www.usenix.org/system/files/srecon22emea_slides_palino_0.pdf">https://www.usenix.org/system/files/srecon22emea_slides_palino_0.pdf</a></p> </div><div class="field-item even"><a class="anchor" name="reference-2"></a><p>Apache Traffic Server ContSchedule: <a href="https://docs.trafficserver.apache.org/en/9.0.x/developer-guide/api/functions/TSContSchedule.en.html">https://docs.trafficserver.apache.org/en/9.0.x/developer-guide/api/funct...</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-3"></a><p>HAProxy Configuration Manual: <a href="https://docs.haproxy.org/dev/configuration.html">https://docs.haproxy.org/dev/configuration.html</a></p> </div><div class="field-item even"><a class="anchor" name="reference-4"></a></div><div class="field-item odd"><a class="anchor" name="reference-5"></a></div><div class="field-item even"><a class="anchor" name="reference-6"></a></div><div class="field-item odd"><a class="anchor" name="reference-7"></a></div></div></div></div></fieldset>

2025/9/17
阅读更多

AI in the Pipeline: Reliability Lessons from Adding an LLM to CI/CD

<div class="field field-name-field-lv2-subtitle field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Lessons learned, pitfalls encountered, and the guardrails that saved us</div></div></div><div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">September 16, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Case Study</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/ai-pipeline-reliability-lessons-adding-llm-cicd#Guruprasad%20Raghothama%20Rao" title="Guruprasad Raghothama Rao">Guruprasad Raghothama Rao</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9461"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Not long ago, the idea of an “AI assistant” inside a build pipeline sounded like science fiction. Code copilots in editors were one thing, but plugging an LLM into CI/CD — the sacred path from commit to deploy — seemed reckless. And yet, as AI gained traction in developer workflows, I found myself wondering: could an AI help us <i>after</i> code was pushed, not just before? Could it speed reviews, flag risks, or even generate quick fixes?</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">This article is about what happened when I tried. Spoiler: the assistant was neither a magic bullet nor a catastrophe — but it forced me to rethink what “reliability” means when your build system starts talking back.</span></span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9462"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">To keep the story clear and accessible, here are the key terms as I’ll use them:</span></span></span></span></p> <ul style="margin-bottom:11px"> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Pull Request (PR):</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> A code change proposal submitted for review before merging into the main branch.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">CI/CD:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Continuous Integration / Continuous Deployment. Automated processes that build, test, and deploy software.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Inline vs. Async AI:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Inline means the AI runs in the critical path of the build pipeline (blocking progress). Async means the AI runs after the build completes, posting results separately.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Validator:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> A lightweight check that confirms or downgrades AI suggestions (e.g., using linters or static analyzers).</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Guardrails:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> The safety mechanisms (validation, circuit breakers, cost controls) that make AI outputs reliable in production environments.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Hallucination:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> When an AI confidently generates a suggestion that is factually wrong or doesn’t exist (e.g., recommending a package that isn’t real).</span></span></span></span></span></li> </ul> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9463"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Context: Why I Tried AI in CI/CD</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">I work on a large-scale, cloud-native platform with micro-frontends, data pipelines, and search clusters serving millions of requests daily. Velocity matters: every week, dozens of Pull Requests (PRs) merge, triggering tests, builds, and deployments. I already used AI locally for code generation and review, but the bottleneck was further down:</span></span></span></span></p> <ul style="margin-bottom:11px"> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Pull Request (PR) reviews sometimes stalled waiting for a human to weigh in.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Test coverage lagged for edge cases.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Deployment checks often required repetitive validation.</span></span></span></span></span></li> </ul> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">The idea was simple: insert an AI assistant into the CI/CD path, where it could:</span></span></span></span></p> <ul style="margin-bottom:11px"> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Add comments to PRs (flagging risky changes).</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Suggest unit tests for uncovered code paths.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Annotate release logs with potential issues.</span></span></span></span></span></li> </ul> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">It sounded futuristic, but achievable.</span></span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9466"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">The First Pipeline Diagram</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Here’s how I imagined the flow:</span></span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9467"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/09c1fUmI0VBdUOZkwceCEa35xbfHHSy9gptdvmSLo88/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9maWd1cmUxX3BpcGVsaW5lLnBuZw" width="1440" height="988" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Pipeline diagram showing the AI Assistant inserted in line between Build &amp; Test and Human Review in the CI/CD flow:</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9482"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">At this stage, the AI assistant was just another hook in the pipeline. Things didn’t go so smoothly.</span></span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9483"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">What Broke First</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">I didn’t ship a Copilot-in-the-cloud. I added an untrusted decision-maker into a safety-critical path. Predictably, it bit me.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">1) Confidently wrong reviews (hallucinated diffs)</span></span></b></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Symptom:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> PR comments flagging issues that didn’t exist.</span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><span style="font-family:Calibri,sans-serif"><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif">AI: </span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Apple Color Emoji&quot;">❌</span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif"> "Line 3: The import 'pandas' is unused — please remove it."</span></span></span></span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-code-excerpt paragraphs-item-code-excerpt paragraphs-item-full paragraphs-item-9484"> <div class="content"> <div class="field field-name-field-code-excerpt field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>import pandas as pd<br> &nbsp;&nbsp;<br> &nbsp; &nbsp;def transform(data):<br> &nbsp; &nbsp; &nbsp; &nbsp;return pd.DataFrame(data) # &lt;-- clearly used here<br> &nbsp;</p> </div></div></div><div class="field field-name-field-code-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Code</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9485"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Cause:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> The model guessed based on patterns, not actual analysis.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Fix:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Treat AI comments as advisory unless validated.</span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">2) Latency cliffs in the critical path</span></span></b></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Symptom:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Pipeline runtime jumped from ~8 minutes to 18–22 minutes.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Cause:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Token-heavy prompts, retries, and inference delays.</span></span></span></span></p> <p><b><span style="font-size:12.0pt"><span style="line-height:115%"><span style="font-family:&quot;Arial&quot;,sans-serif">Fix:</span></span></span></b><span style="font-size:12.0pt"><span style="line-height:115%"><span style="font-family:&quot;Arial&quot;,sans-serif"> Move AI off the critical path and add circuit breakers.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9486"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/qyka4srKmLILnGll9Ngs76lfnsdSV7E80rPpUaW0OXM/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9maWd1cmUyX2xhdGVuY3lfMC5wbmc" width="1098" height="749" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Pipeline runtime before and after AI integration, highlighting latency increases when inference was added inline</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9487"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">3) Cost spikes</span></span></b></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Symptom:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> “Pennies per call” turned into runaway bills at scale.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Cause:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Dozens of PRs × multiple prompts × retries.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Fix:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Rate limiting, token caps, and auto-disabling when thresholds exceeded.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">4) Bad suggestions in unfamiliar stacks</span></span></b></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Symptom:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> In one case, the AI confidently recommended adding Jest (a JavaScript testing framework) in a repository that wasn’t even using JavaScript.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Fix:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Add a repo profile to prompts and enforce stack guards to prevent stack mismatches.</span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">5) Extra burden on reviewers</span></span></b></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Symptom:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Reviewers felt obligated to fix every AI suggestion.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Fix:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Mark AI feedback as “[Advisory]” unless validated.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">6) Risky release note summaries</span></span></b></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Symptom:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> AI hallucinated a breaking change:</span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><span style="font-family:Calibri,sans-serif"><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif">AI Release Notes: "</span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Apple Color Emoji&quot;">⚠️</span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif"> Breaking change: API endpoint /v2/search removed"</span></span></span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><span style="font-family:Calibri,sans-serif"><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif">Reality: Endpoint still existed — AI inferred this from a refactor.</span></span></span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Fix:</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Only summarize merged commits; require human sign-off on version bumps.</span></span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9488"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Guardrails: Making AI Safe in CI/CD</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Guardrails turned an interesting demo into a production-worthy tool. The theme: <b>async first, validate everything, fail safe</b>.</span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">Validation as First-Class</span></span></b></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">AI output is untrusted input. I built cheap, layered checks to keep noise out:</span></span></span></span></p> <ul style="margin-bottom:11px"> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Static analysis confirmation</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> (linters, type checkers).</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Test oracles</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> (run test suites on AI-generated tests).</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Stack guards</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> (reject mismatched tools).</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Dependency checks</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> (verify existence, allow-list).</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Security gates</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> (block unsafe code suggestions).</span></span></span></span></span></li> </ul> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-code-excerpt paragraphs-item-code-excerpt paragraphs-item-full paragraphs-item-9489"> <div class="content"> <div class="field field-name-field-code-excerpt field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p># scripts/validate_ai_suggestions.py<br> &nbsp;import subprocess<br> &nbsp;&nbsp;<br> &nbsp;def is_unused_import_real(py_files):<br> &nbsp; &nbsp; &nbsp;r = subprocess.run(["flake8", "--select=F401", *py_files],<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; capture_output=True, text=True)<br> &nbsp; &nbsp; &nbsp;return "F401" in r.stdout<br> &nbsp;&nbsp;<br> &nbsp;def matches_repo_profile(suggestion, profile):<br> &nbsp; &nbsp; &nbsp;if "jest" in suggestion.lower() and profile["lang"] != "javascript":<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return True<br> &nbsp; &nbsp; &nbsp;return False<br> &nbsp;&nbsp;<br> &nbsp;def validate(ai_comment, changed_files, profile):<br> &nbsp; &nbsp; &nbsp;issues = []<br> &nbsp; &nbsp; &nbsp;if "unused import" in ai_comment.lower() and not is_unused_import_real(changed_files.get("py", [])):<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;issues.append("unused-import-hallucination")<br> &nbsp; &nbsp; &nbsp;if matches_repo_profile(ai_comment, profile):<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;issues.append("stack-mismatch")<br> &nbsp; &nbsp; &nbsp;return issues</p> </div></div></div><div class="field field-name-field-code-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Code Snippet: Python validator for hallucinated imports and stack mismatches</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9490"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Example flow:</span></b></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><span style="font-family:Calibri,sans-serif"><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif">AI: </span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Apple Color Emoji&quot;">❌</span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif"> "Null pointer possible at line 128."</span></span></span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><span style="font-family:Calibri,sans-serif"><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif">Validator: </span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Apple Color Emoji&quot;">⚠️</span></span><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif"> Could not confirm with static analysis.</span></span></span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:45.8pt 91.6pt 137.4pt 183.2pt 229.0pt 274.8pt 320.6pt 366.4pt 412.2pt 458.0pt 503.8pt 549.6pt 595.4pt 641.2pt 687.0pt 732.8pt"><span style="font-family:Calibri,sans-serif"><span style="font-size:10.0pt"><span style="font-family:&quot;Arial&quot;,sans-serif">Posted: [Advisory] Possible null pointer (unconfirmed).</span></span></span></span></span></span></p> <p><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">Async, Not Inline</span></span></b></span></span></span></p> <p><span style="font-size:12.0pt"><span style="line-height:115%"><span style="font-family:&quot;Arial&quot;,sans-serif">Inline inference killed velocity. I moved AI to an <b>async path</b>: if build and tests passed, a bot posted AI comments afterward.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9491"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/S-3nqzczXWh8pekuA_eF66lwgM6zJrmXC5z66WBhRMo/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9maWd1cmUzX2FzeW5jX3BpcGVsaW5lXzAucG5n" width="1440" height="859" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Async pipeline diagram showing AI bot posts comments after build/test passes, avoiding critical-path latency</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-code-excerpt paragraphs-item-code-excerpt paragraphs-item-full paragraphs-item-9492"> <div class="content"> <div class="field field-name-field-code-excerpt field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p># .github/workflows/pr-ai-review.yml<br> &nbsp;jobs:<br> &nbsp; &nbsp;build:<br> &nbsp; &nbsp; &nbsp;runs-on: ubuntu-latest<br> &nbsp; &nbsp; &nbsp;steps:<br> &nbsp; &nbsp; &nbsp; &nbsp;- uses: actions/checkout@v4<br> &nbsp; &nbsp; &nbsp; &nbsp;- run: npm ci &amp;&amp; npm test<br> &nbsp;&nbsp;<br> &nbsp; &nbsp;ai-review:<br> &nbsp; &nbsp; &nbsp;needs: build<br> &nbsp; &nbsp; &nbsp;if: needs.build.result == 'success'<br> &nbsp; &nbsp; &nbsp;runs-on: ubuntu-latest<br> &nbsp; &nbsp; &nbsp;steps:<br> &nbsp; &nbsp; &nbsp; &nbsp;- uses: actions/checkout@v4<br> &nbsp; &nbsp; &nbsp; &nbsp;- name: Generate AI Review<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;run: |<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;python scripts/ai_reviewer.py \<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;--pr ${{ github.event.pull_request.number }} \<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;--out comments.json<br> &nbsp; &nbsp; &nbsp; &nbsp;- name: Validate &amp; Post<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;run: |<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;python scripts/validate_and_post.py comments.json</p> </div></div></div><div class="field field-name-field-code-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Code Snippet: GitHub Actions async AI review job</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9493"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><b><span style="font-size:13.5pt"><span style="font-family:&quot;Arial&quot;,sans-serif">Circuit Breakers</span></span></b></span></span></span></p> <p><span style="font-size:12.0pt"><span style="line-height:115%"><span style="font-family:&quot;Arial&quot;,sans-serif">When using the LLM model to check an update, if cost or latency thresholds were exceeded, the AI stage automatically disabled itself until manually reset. This prevented runaway GPU spend.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-code-excerpt paragraphs-item-code-excerpt paragraphs-item-full paragraphs-item-9494"> <div class="content"> <div class="field field-name-field-code-excerpt field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>#!/usr/bin/env bash<br> &nbsp;set -euo pipefail<br> &nbsp;&nbsp;<br> &nbsp;START=$(date +%s)<br> &nbsp;MAX_SEC=30<br> &nbsp;&nbsp;<br> &nbsp;resp=$(ai-cli generate "$@" || true)<br> &nbsp;ELAPSED=$(( $(date +%s) - START ))<br> &nbsp;&nbsp;<br> &nbsp;if [ $ELAPSED -gt $MAX_SEC ] || [ -z "$resp" ]; then<br> &nbsp; &nbsp;echo "AI step skipped (elapsed=${ELAPSED}s)" &gt;&amp;2<br> &nbsp; &nbsp;exit 0<br> &nbsp;fi<br> &nbsp;&nbsp;<br> &nbsp;printf "%s" "$resp"</p> </div></div></div><div class="field field-name-field-code-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Code Snippet: Bash circuit breaker wrapper</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9495"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Example: Good vs. Hallucinated Suggestions</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Before diving into the comparison, it’s worth grounding this with a few quick checks. In practice, the difference between a <em data-end="366" data-start="358">useful</em> AI suggestion and a <em data-end="402" data-start="387">hallucination</em> often came down to simple tests: running a suggested edge-case test, verifying whether a dependency actually existed, or confirming with static analysis. These small validations highlighted the split between genuine value and misleading noise.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9496"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/2CNPUmE4195c1RnFvd3ggPaVlcJSzgnDF0YF67MjYXA/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9maWd1cmU0X2NvbXBhcmlzb25fMC5wbmc" width="1374" height="444" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Comparison table of AI outputs, illustrating useful vs. hallucinated suggestions and their outcomes</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9497"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">What Worked Surprisingly Well</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><ul style="margin-bottom:11px"> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Test Suggestions.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> One AI-generated test saved me:</span></span></span></span></span></li> </ul> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-code-excerpt paragraphs-item-code-excerpt paragraphs-item-full paragraphs-item-9498"> <div class="content"> <div class="field field-name-field-code-excerpt field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>&nbsp;def test_empty_input_payload():<br> &nbsp; &nbsp; &nbsp;result = transform([])<br> &nbsp; &nbsp; &nbsp;assert result == []</p> </div></div></div><div class="field field-name-field-code-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Code</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9499"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">This trivial case revealed a regression where the transform function blew up on empty lists.</span></span></span></span></p> <ul style="margin-bottom:11px"> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Release Notes.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> AI summaries sped up QA and PM handoffs.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Knowledge Transfer.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Junior developers used AI comments flagged as “[Advisory]” as prompts to learn.</span></span></span></span></span></li> </ul> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9500"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Lessons Learned</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><ul style="margin-bottom:11px"> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">AI is untrusted input.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Validate before acting.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Don’t block pipelines.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Async keeps velocity.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Guardrails are mandatory.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Cost/latency breakers are non-negotiable.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Expect culture shock.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Engineers need clear guidance.</span></span></span></span></span></li> <li style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="tab-stops:list .5in"><span style="font-family:Calibri,sans-serif"><b><span style="font-family:&quot;Arial&quot;,sans-serif">Focus on leverage.</span></b><span style="font-family:&quot;Arial&quot;,sans-serif"> Release notes + tests delivered ROI.</span></span></span></span></span></li> </ul> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9501"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Conclusion: Trust, but Verify</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">Putting AI in a CI/CD pipeline isn’t about automating developers out of the loop. It’s about augmentation — faster feedback, better documentation, more edge cases caught. But without guardrails, the costs (latency, money, trust) outweigh the benefits.</span></span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:normal"><span style="font-family:Calibri,sans-serif"><span style="font-family:&quot;Arial&quot;,sans-serif">The real lesson: when your build system starts talking back, treat it with the same skepticism you’d give any external service. Trust, but verify. And never forget that reliability is the first feature.</span></span></span></span></p> </div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a></div><div class="field-item even"><a class="anchor" name="reference-2"></a></div><div class="field-item odd"><a class="anchor" name="reference-3"></a></div><div class="field-item even"><a class="anchor" name="reference-4"></a></div><div class="field-item odd"><a class="anchor" name="reference-5"></a></div><div class="field-item even"><a class="anchor" name="reference-6"></a></div><div class="field-item odd"><a class="anchor" name="reference-7"></a></div><div class="field-item even"><a class="anchor" name="reference-8"></a></div></div></div></div></fieldset>

2025/9/15
阅读更多

Evaluating AI Agents at Production Scale: A Multi-Signal Framework

<div class="field field-name-field-lv2-subtitle field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Lessons from Generating Thousands of Mobile Apps Daily</div></div></div><div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">September 12, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Case Study</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/evaluating-ai-agents-production-scale-multi-signal-framework#Nikita%20Kryzhanouski" title="Nikita Kryzhanouski">Nikita Kryzhanouski</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9454"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">When Single Metrics Break Down</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>When you're generating thousands of AI outputs daily, traditional evaluation approaches hit a wall. The problem isn't technical complexity—it's that the metrics we rely on for smaller systems fundamentally don't capture what matters at scale.</p> <p>Take response latency. Your monitoring dashboard shows the model generated code in 2.3 seconds. Great! But if that code crashes when users try to run it, the speed is meaningless. Users will happily wait ten minutes for something that actually works rather than get instant garbage.</p> <p>Or consider user ratings. You add thumbs up/down buttons to capture satisfaction. Sounds reasonable, except users are loss-averse by nature. They'll definitely hit dislike when something breaks, but they rarely bother with like when everything works as expected. You end up measuring frustration more accurately than satisfaction, which skews your optimization in the wrong direction.</p> <p>At Rork App, we learned this lesson while scaling our AI-generated React Native apps from tens to thousands per day. Traditional metrics that felt scientific and objective were actually steering us away from what users needed. What we discovered is that effective evaluation requires multiple perspectives working together, with AI-powered analysis filling the gaps that surveys and simple metrics can't reach.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9455"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">A Multi-Signal Evaluation Framework</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>The solution we built combines four different types of signals. Think of them as different lenses for looking at the same problem—each one shows you something the others miss.</p> <h3>1. Behavioral Signals: What Users Actually Do</h3> <p>The most honest signal comes from watching user actions, not asking for opinions. When someone reverts a generated app version, that's a costly decision. They're throwing away time and progress, which means they're genuinely dissatisfied with what they got.</p> <p>We track these revert events along with context: which model generated the app, how complex the request was, how long before the user gave up. Unlike survey responses, behavioral data doesn't lie because it's expensive. Users might tell you they're happy to be polite, but they won't waste their own time to be nice.</p> <p>The downside is that behavioral signals only capture one side of the story. You see when users are frustrated enough to take action, but plenty of users just tolerate mediocre results without reverting. Others have unrealistically high standards and revert even minor issues. So while revert rates are a strong signal of failure, they don't tell you much about success.</p> <h3>2. AI-Powered Intent Classification: Predicting User Momentum</h3> <p>Here's where AI evaluation of AI outputs gets interesting. Instead of asking users "how satisfied are you?" we analyze their messages to predict "are you making progress toward something real?"</p> <p>We built a classifier that uses GPT-4 to score every user message on a scale from -10 (about to churn) to +10 (ready to ship). The key insight is that user satisfaction correlates with momentum toward their goals, not with perfect outputs.</p> <p><strong>Churn Risk Territory:</strong></p> <ul> <li>completely_stuck (-10): "Nothing works anymore", "The app won't even start"</li> <li>major_blocker (-7): "Login doesn't work at all", "Can't save any data"&nbsp;&nbsp;</li> <li>frustrated (-4): "There are bugs everywhere", "Why does nothing work properly?"</li> <li>polish_issues (-2): "Fix this typo", "The button color is wrong"</li> </ul> <p><strong>Neutral Ground:</strong></p> <ul> <li>exploring (0): "How do I add authentication?", "What's possible with this tool?"</li> </ul> <p><strong>Progress Territory:</strong></p> <ul> <li>iterating (+3): "Make this button bigger", "Change the color scheme"</li> <li>building (+6): "Add a settings screen", "Create user profiles"</li> <li>expanding (+9): "Add a complete payment system", "Build an admin dashboard"</li> <li>shipping (+10): "Add app store screenshots", "Prepare for app store submission"</li> </ul> <p>The classifier analyzes three things simultaneously: Where is this user in their journey to build something real? Are they moving forward or stuck? How likely are they to keep using the platform?</p> <p>What makes this powerful is that it runs in real-time. When a user drops to -4, we can proactively reach out with support before they churn. When someone hits +9, we know they're a candidate for our showcase program. Traditional surveys would require us to interrupt users and hope they respond honestly.</p> <p>The validation numbers tell the story: intent scores predict 30-day retention with 67% correlation. That's nearly double what we get from satisfaction surveys (34% correlation) and significantly better than pure behavioral metrics like session frequency (41% correlation).</p> <h3>3. Technical Quality Metrics: The Engineering Health Check</h3> <p>Technical metrics don't predict user happiness directly, but they reveal systematic problems before users complain about them. We track compilation errors, runtime exceptions, generation failures, and library usage mistakes.</p> <p>The real value here is pattern recognition. If TypeScript property errors spike 15% in one week, that suggests prompt degradation or model drift. Users might not report these issues immediately, but the technical data gives us early warning that something's wrong with our system.</p> <p>These metrics are also crucial for guiding prompt engineering. After analyzing thousands of errors, we discovered that 94% came from just five error types. That insight directly shaped how we restructured our system prompts to avoid the most common mistakes.</p> <h3>4. Functional Capability Benchmarks: Testing What Actually Matters</h3> <p>The final piece is structured testing of whether generated outputs actually work for their intended purpose. We break this down by category—games need animation and physics, photography apps need camera integration and image processing, social platforms need real-time messaging and user profiles.</p> <p>For each category, we define what "working" means through boolean evaluation criteria. A photography app passes if the camera component renders without errors, photo capture works, at least three filters are available, filter preview updates in real-time, and edited photos can be saved to the device.</p> <p>This is expensive to run comprehensively—testing 30 prompts with 30 checks each requires significant time and effort. But it's the only way to definitively answer "does this system generate apps that actually work?" When we need statistical confidence for major decisions, functional benchmarks provide the rigor that other signals can't match.</p> <p>The trick is knowing when you need that level of precision. Most changes only affect narrow capabilities, so we can test just the relevant functionality instead of running full evaluations. Authentication improvements get auth-specific tests, navigation changes get navigation-focused prompts.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9456"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Deep Dive: AI-Powered Intent Analysis</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>The most innovative component of our framework transforms subjective user satisfaction into objective momentum prediction through structured prompt engineering.</p> <h3>Prompt Architecture</h3> <p><em>const prompt = `</em></p> <p><em>&nbsp; # User Journey Intent Classification<br> &nbsp; Classify user messages based on their progress toward building a working app and likelihood to continue using the platform.</em></p> <p><em>&nbsp; ## NEGATIVE MOMENTUM (Churn Risk)<br> <br> &nbsp; **completely_stuck** (-10): App is completely unusable, user likely to abandon<br> &nbsp; - "Nothing works anymore"<br> &nbsp; - "The app won't even start"<br> &nbsp; - "I can't do anything"<br> &nbsp; - "This is completely broken"</em></p> <p><em>&nbsp; **major_blocker** (-7): Core functionality is broken, significant friction<br> &nbsp; - "Login doesn't work at all"<br> &nbsp; - "Can't save any data"<br> &nbsp; - "The whole navigation is broken"<br> &nbsp; - "Users can't sign up"</em></p> <p><em>&nbsp; **frustrated** (-4): Multiple issues, user losing confidence in the tool<br> &nbsp; - "There are bugs everywhere"<br> &nbsp; - "Why does nothing work properly?"<br> &nbsp; - "This keeps breaking"<br> &nbsp; - "So many errors"</em></p> <p><em>&nbsp; **polish_issues** (-2): Minor problems, cosmetic fixes needed<br> &nbsp; - "Fix this typo"<br> &nbsp; - "The button color is wrong"<br> &nbsp; - "Text is misaligned"<br> &nbsp; - "Small spacing issue"</em></p> <p><em>&nbsp; ## NEUTRAL (0)</em></p> <p><em>&nbsp; **exploring** (0): Learning, planning, not yet committed to building<br> &nbsp; - "How do I add authentication?"<br> &nbsp; - "What's possible with this tool?"<br> &nbsp; - "Can you explain how this works?"<br> &nbsp; - "What's the best approach?"</em></p> <p><em>&nbsp; ## POSITIVE MOMENTUM (Retention)</em></p> <p><em>&nbsp; **iterating** (+3): Improving existing features, making steady progress<br> &nbsp; - "Make this button bigger"<br> &nbsp; - "Change the color scheme"<br> &nbsp; - "Improve the layout"<br> &nbsp; - "Add loading states"</em></p> <p><em>&nbsp; **building** (+6): Adding new functionality, clear forward momentum<br> &nbsp; - "Add a settings screen"<br> &nbsp; - "Create user profiles"<br> &nbsp; - "Add search functionality"<br> &nbsp; - "Build a shopping cart"</em></p> <p><em>&nbsp; **expanding** (+9): Scaling up significantly, high engagement with project<br> &nbsp; - "Add a complete payment system"<br> &nbsp; - "Create a multi-step onboarding flow"<br> &nbsp; - "Build an admin dashboard"<br> &nbsp; - "Add real-time notifications"</em></p> <p><em>&nbsp; **shipping** (+10): Approaching real product, preparing for users<br> &nbsp; - "Add app store screenshots"<br> &nbsp; - "Set up production environment"<br> &nbsp; - "Create onboarding for real users"<br> &nbsp; - "Prepare for app store submission"</em></p> <p><em>&nbsp; ## Classification Principles</em></p> <p><em>&nbsp; 1. **Focus on user journey stage**: Where are they in building a real app?<br> &nbsp; 2. **Assess momentum**: Are they moving forward or stuck?<br> &nbsp; 3. **Consider retention risk**: How likely are they to continue using the platform?<br> &nbsp; 4. **Value proximity**: How close are they to having something useful?</em></p> <p><em>&nbsp; ## Key Distinctions</em></p> <p><em>&nbsp; - **Stuck vs Frustrated**: Stuck = specific blocker, Frustrated = losing faith<br> &nbsp; - **Building vs Expanding**: Building = new features, Expanding = complex systems<br> &nbsp; - **Iterating vs Exploring**: Iterating = improving existing, Exploring = learning</em></p> <p><em>`</em></p> <p>Our intent classifier uses a hierarchical prompt structure with three key components:</p> <p><strong>Category definitions with behavioral anchors</strong>: Each intent level includes specific user language patterns and contextual markers. "Completely stuck" maps to phrases like "nothing works anymore" and "I can't do anything," while "shipping" corresponds to "prepare for app store submission" and "set up production environment."</p> <p><strong>Classification principles</strong>: The prompt emphasizes outcome-focused evaluation: proximity to user goals, forward momentum assessment, and retention risk prediction. This grounds subjective language analysis in objective business metrics.</p> <p><strong>Confidence scoring</strong>: Every classification includes certainty measurement, enabling human review of edge cases and continuous prompt improvement.</p> <h3>Operational Integration</h3> <p>Intent scores trigger automated workflows: users below -4 receive proactive support outreach, users above +6 get feature expansion suggestions, and users at +9-10 enter our product showcase pipeline.</p> <p>This transforms reactive customer service into predictive user success management.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9457"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">What We Tried That Didn't Work</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Our path to this framework went through several dead ends that taught us important lessons about what evaluation can and can't do.</p> <p>Human taste at small scale was our first approach. Engineers would test a few apps and declare which model "felt better." This worked fine when we generated dozens of apps per day, but collapsed as we scaled. "Better" had no consistent definition—sometimes it meant fewer crashes, other times it meant the app looked nicer. Human judgment varies wildly between evaluators and doesn't scale beyond small teams.</p> <p>User voting seemed like the obvious solution. We built A/B testing infrastructure with like/dislike buttons, thinking we'd solved the evaluation problem by measuring user preference directly. The flaw revealed itself quickly: people are loss-averse. Users whose apps crashed would definitely hit dislike, but users whose apps worked perfectly often couldn't be bothered with like. We were systematically over-measuring negative experiences and under-measuring positive ones.</p> <p>Pure error tracking felt more scientific. We categorized every TypeScript error, bundle failure, and generation timeout. This gave us fascinating insights—agentic AI clearly outperformed single-call models on complex projects, while simple models excelled at contained edits. But once we started optimizing prompts, the data turned slippery. One error type would drop 4% while another rose 4%. Net improvement was unclear, and neither our team nor users could confidently say the experience had actually gotten better.</p> <p>Revert rates were more promising because they measured costly user actions rather than opinions. But the signal was incomplete. Some users tolerated mediocre results and never reverted. Others had unrealistically high standards and reverted minor cosmetic issues. Reverts told us clearly when we'd failed, but they didn't tell us when we'd succeeded.</p> <p>Each approach captured something valuable but insufficient. The breakthrough was realizing we didn't need to find the perfect metric—we needed to combine complementary signals that covered each other's blind spots.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9458"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Implementation Guidelines for Production Teams</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><h3>When Each Signal Type Matters Most</h3> <p>Behavioral monitoring should be always-on once you're generating more than a few hundred outputs daily. It's your canary in the coal mine—when revert rates or abandonment spikes, something's wrong with your system even if you don't know what yet.</p> <p>Intent classification becomes critical when user success depends on sustained engagement over multiple sessions. If people need to iterate and refine outputs to achieve their goals, understanding their momentum is essential. For simple one-shot tasks, it's probably overkill.</p> <p>Technical metrics are indispensable for engineering-driven optimization. They guide prompt engineering, reveal systematic failures, and help you understand why certain improvements work. But they're means, not ends—optimize technical metrics to improve user outcomes, not for their own sake.</p> <p>Functional benchmarks are your heavyweight evaluation tool. Use them for major releases, competitive analysis, and when you need statistical confidence for important decisions. They're too expensive to run continuously, but irreplaceable when you need definitive answers.</p> <h3>Resource Allocation and Team Structure</h3> <p>Once your AI system generates more than 1,000 outputs daily, assign dedicated evaluation engineering resources. Shared responsibility creates bottlenecks and inconsistent measurement practices. Budget roughly 15-20% of your AI development resources for evaluation infrastructure—this includes building classification models, automating data pipelines, and developing statistical analysis capabilities.</p> <p>For tooling, use commercial solutions like Langfuse or Weights &amp; Biases for basic tracking and visualization. But expect to build custom components for domain-specific evaluation logic and multi-signal orchestration. Every production AI application has unique success criteria that generic tools can't capture.</p> <h3>Beyond Mobile Apps: Broader Applications</h3> <p>This multi-signal approach generalizes well to other production AI applications. Code generation platforms can combine code acceptance rates (behavioral), developer problem-solving progression analysis (intent), compilation success (technical), and task completion rates (functional). Content creation systems might track engagement patterns, audience response prediction, quality metrics, and format-specific capability testing.</p> <p>The core principle stays the same: combine economically honest behavioral signals, AI-powered outcome prediction, objective technical measurement, and structured capability testing. The specific metrics change, but the framework of multiple complementary perspectives remains constant.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9459"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">The Future of AI Evaluating AI</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>As AI systems handle more complex and diverse tasks, evaluation must evolve from measuring accuracy to predicting outcomes. The most promising directions involve cross-modal evaluation that combines text, code, visual, and behavioral signals, predictive evaluation that uses early interaction patterns to forecast long-term success, and adaptive evaluation that dynamically adjusts measurement strategies based on user behavior.</p> <p>The fundamental insight driving this evolution is that effective evaluation measures user outcomes, not system outputs. What matters isn't whether the AI produces syntactically correct code or grammatically proper text—it's whether users achieve meaningful goals with those outputs.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9460"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Conclusion: Evaluation as Strategic Leverage</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Production AI evaluation isn't about finding perfect metrics—it's about building systematic approaches that acknowledge uncertainty while providing actionable insights. Single metrics, whether technical, behavioral, or survey-based, capture important signals but miss the complexity of real-world success.</p> <p>Our multi-signal framework demonstrates that AI can effectively evaluate AI at scale through structured analysis and automated outcome prediction. By combining behavioral honesty, predictive intent analysis, technical monitoring, and functional validation, you can build evaluation systems that guide optimization toward user success rather than metric gaming.</p> <p>The most important insight for production teams: evaluation is strategic leverage. What you measure determines what you optimize. Focus on user outcomes rather than system convenience, combine complementary signals to eliminate blind spots, and invest in AI-powered analysis to scale beyond human evaluation limits. The question isn't whether to invest in comprehensive evaluation—it's whether to build systems that predict user success or remain trapped optimizing for metrics that don't actually matter.</p> </div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a></div><div class="field-item even"><a class="anchor" name="reference-2"></a></div><div class="field-item odd"><a class="anchor" name="reference-3"></a></div><div class="field-item even"><a class="anchor" name="reference-4"></a></div><div class="field-item odd"><a class="anchor" name="reference-5"></a></div></div></div></div></fieldset>

2025/9/11
阅读更多

Catch-22: Detecting Compromised SSH Servers with SSH Public Keys

<div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">September 7, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Research</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#Cristian%20Munteanu" title="Cristian Munteanu">Cristian Munteanu</a>, <a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#Tobias%20Fiebig" title="Tobias Fiebig">Tobias Fiebig</a>, <a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#Georgios%20Smaragdakis" title="Georgios Smaragdakis">Georgios Smaragdakis</a>, <a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#Anja%20Feldmann" title="Anja Feldmann">Anja Feldmann</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9445"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Secure SHell (SSH) is one of the most common tools used to manage servers remotely. It protects communication between administrators and machines and is considered one of the core protocols of the Internet. Because it is everywhere, SSH is also one of the main entry points for attackers.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">When attackers gain access to a server, they often want to maintain control for as long as possible. A common technique is to install their own SSH keys, allowing them to log in again at any time without relying on the original password. This approach is both simple and stealthy: the legitimate user’s password remains unchanged, so typical alerts based on password misuse are never triggered. Detecting this kind of compromise across the Internet is not a trivial task.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Existing defenses, such as system logs, intrusion detection systems, or honeypots, have important limits. Logs can be deleted, detection systems often generate false alerts, and honeypots only see a fraction of the real attacks. What we wanted was a method that could track compromised systems at Internet scale, reliably, and without needing inside access to a server.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">At <b>USENIX Security 2025</b>, we presented <a href="https://www.usenix.org/conference/usenixsecurity25/presentation/munteanu" target="_blank"><i>Catch-22: Uncovering Compromised Hosts using SSH Public Keys</i></a>. Our method makes use of a <sdt id="-1021265236" sdttag="goog_rdk_0"></sdt>mechanism in the SSH protocol that allows us to test whether a server is compromised – without needing to break into it.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9446"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">How it works</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Our approach relies on the way SSH handles public key authentication. In SSH, authentication with keys works as a pair: the client keeps the private key, while the server stores the corresponding public key in its authorized list. The SSH private key file does not only store the private key but also includes the corresponding public key. When a client attempts to log in, it offers a public key to the server, the server checks if that key is present on its list of authorized keys for the account the user tries to authenticate to. The private key is never <sdt id="-422089416" sdttag="goog_rdk_1"></sdt>sent to the server; it remains on the client and is only used to prove identity by correctly answering the server’s cryptographic challenge. To prevent Denial-of-Service attacks, i.e., attackers forcing the server to perform public key encryption of an endless number of challenges, the server <i>only </i>responds with a cryptographic challenge if the key is actually authorized for the user account. If the key is not present, the server will return an error. For most users this detail is invisible, but from a security perspective it is extremely valuable.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">When an attacker gets access to a server, they usually install their own public keys in order to ensure future access. Hence: <u>If we probe a server with a public key that is known to belong to a malicious actor and the server responds with a challenge, we know that the attacker’s key has been installed on the server.</u> This way, a server silently reveals whether or not it has been compromised by an attacker. The general mechanism behind this was first described by Siebenmann<a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#reference-1">[1]</a>&nbsp;in 2016 and later noted by Golubin<a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#reference-2">[2]</a>&nbsp;in 2019, who showed that it could be used to identify infrastructure linked to GitHub users. Building on this foundation, our work demonstrates how the same mechanism can be used systematically at Internet scale to uncover compromised machines. Using this method we can perform active measurements to test if a system is likely to be compromised. The figure below illustrates two scenarios: one in which a challenge is sent because the key exists, and another showing the error that occurs when no key is found. The red line indicates the point at which our scan terminates.</span></span></span></p> <p style="margin-bottom:11px">&nbsp;</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9447"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/aJy1MjM145WwqM7i-yCsltZIqbQY4hSYdoN0RiktqXM/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9zc2hfaGFuZHNoYWtlX2FydGljbGVfMi5qcGc" width="1440" height="991" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">These figures illustrate two cases of SSH authentication using a public key. On the left a challenge is sent because the key exists, and on the right – an error – that occurs when no key is found. The red line indicates where our scan terminates.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9448"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Scaling the Idea</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">To take this idea beyond a proof of concept, we built an Internet-scale measurement pipeline that tests whether <b>real attacker keys</b> are installed on hosts in the Internet. In collaboration with our partner Bitdefender, we collected <b>52 SSH public keys</b> linked to malicious activity. These keys had been identified through honeypots, malware analysis, and incident response.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">For each key, we initiated SSHv2 authentication to hosts found to run SSH in Internet-wide active measurements, by presenting, in multiple rounds, the three most commonly compromised usernames together with the public key. Checking whether the servers return a challenge whether the keys are installed on these systems, i.e., the systems are likely compromised. Importantly, <b>we do not have access to the private keys</b>, and cannot complete the authentication even if a key was found to be installed; the probe ended immediately after the challenge stage.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">We implemented this logic as a patch to the <a href="https://github.com/zmap/zgrab2">Zgrab2</a>&nbsp;scanner, and, with the help of <a href="https://github.com/zmap/zmap">ZMap</a>, scanned the Internet (IPv4 <i>and </i>IPv6) for hosts running SSH on the standard SSH port (tcp/22) as well as the most common SSH off port (tcp/2222). The study ran in <b>11 rounds</b> beginning in April 2024 and finishing by August 2024, rotating through selected usernames (<i>the names were selected based on the provided data from Bitdefender</i>) such as <u>root</u>,<i><u> admin</u></i>, and<u> udatabase</u> and inserting pauses between rounds to avoid overloading systems and disturbing system administrators worldwide. Because a small fraction of endpoints might respond with a challenge to <i>any</i> key – such as misconfigured SSH servers or honeypots – in every round we first tested each host with a “<b>canary key”</b> of the same algorithm before trying the malicious key. </span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">A <b>canary key</b> is a harmless test key <sdt id="933416030" sdttag="goog_rdk_3"></sdt>that we freshly generated to ensure that it should <i>not</i> be present on <i>any </i>host on the Internet. If a server responds with a challenge to this canary key, we know that the server incorrectly reacts to <i>any</i> public key, allowing us to filter out such misconfigured or possibly honeypot systems before probing with real attacker keys. If the canary elicited a challenge, we excluded that host from testing. This applied to about <b>0.2%</b> of the measured population.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Before scaling up, we validated the method extensively. We tested different SSH implementations, including <a href="https://www.openssh.com/">OpenSSH</a>, <a href="https://matt.ucc.asn.au/dropbear/dropbear.html">Dropbear</a>, <a href="https://bitvise.com/ssh-server">BitviseSSH</a>, and <a href="https://www.wolfssl.com/products/wolfssh/">WolfSSH</a>, to confirm consistent behavior. We also ran controlled scans against networks that had explicitly consented to be included, verifying that our probes were safe and correct. To support further work, we released our patched scanner and automation scripts to the public<a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#reference-3">[3]</a>.</span></span></span></p> <div> <div> <div class="msocomtxt" id="_com_2" language="JavaScript" onmouseout="msoCommentHide('_com_2')" onmouseover="msoCommentShow('_anchor_2','_com_2')"> <p class="MsoCommentText" style="margin-bottom:11px">&nbsp;</p> </div> </div> </div> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9449"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Our findings</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">The measurement campaign revealed more than 16 thousand SSH servers worldwide that recognized one of the 52 attacker keys. These were not only low-value personal machines but also systems in hosting environments, academic institutions, and enterprise networks. In many cases, the servers we flagged matched known botnet infrastructures or malware command-and-control hosts, confirming that the method uncovered real compromises.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Perhaps most important was the accuracy of the signal. Because a server must explicitly recognize a key for us to record it as compromised, false positives were rare. The few anomalies we observed were usually linked to misconfigurations rather than attacks, which underscores the reliability of the approach.</span></span></span></p> <div style="border:none black 1.0pt; padding:0in 0in 0in 0in"> <p style="border: none; padding: 0in; margin-bottom: 11px;"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif"><span lang="EN" style="font-family:&quot;Arial&quot;,sans-serif" xml:lang="EN"><span style="color:black">Among our findings, one stood out for both its rarity and significance: one of the compromised hosts was actually a core router belonging to a Internet Service Provider in central Europe. This router responded to an attacker-linked public key – specifically <i>mkey-06</i>. Given that this device was just one or two network hops from the ISP’s border, its compromise illustrates that SSH key-based persistence can extend into critical infrastructure, not just end-hosts. This case underscores the breadth of environments where such attacks can occur – and highlights the importance of a detection method capable of spanning diverse host types, from ordinary servers to core networking equipment.</span></span></span></span></span></p> <p style="border: none; padding: 0in; margin-bottom: 11px;"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">The results are also illustrated in two figures. The first presents a world map showing the geographic distribution of compromised hosts. The map makes clear that these systems are spread across all regions, with concentrations in Europe, North America, and Asia, reflecting both global deployment of SSH and the global reach of attacker operations. The second figure summarizes how many hosts recognized each malicious key. Each bar corresponds to one of the attacker keys (mkeys), while the color within the bar represents the proportion of accounts that were compromised under different usernames.</span></span></span></p> <p style="border: none; padding: 0in; margin-bottom: 11px;">&nbsp;</p> </div> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9450"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/22LBCRkkOrwVHzlFEf-L5mPypBUgfn_KLIU5OhS21dE/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9yb3VuZDFfMjJfc3NoX21hbF9rZXlfbWFwXzMucG5n" width="1440" height="500" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">World distribution of compromised SSH hosts.</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9451"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/YChNVdY7CVfGDZMSrjTsrRwwPXPtd78d9bjOXsu4wxc/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9yb3VuZDFfMjJfc3NoX21hbF9rZXlfdnNfdXNlcm5hbWVfMS5qcGc" width="1440" height="655" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Distribution of malicious keys over the compromised hosts underlining the ratio of found compromised accounts.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9452"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Implications and Collaboration</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">The ability to identify compromised hosts at Internet scale has several important applications. For global security monitoring, SSH key probing can be integrated into regular Internet scans, providing visibility into the scope and distribution of compromises. For enterprises and universities, the method can be used internally to ensure that no known malicious SSH keys are present across their infrastructure, adding an extra layer of assurance to existing security practices. In the area of threat intelligence, the ability to tie compromised hosts to attacker keys enriches attribution efforts and allows faster detection of coordinated campaigns.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">An important aspect of the technique is that it is difficult for attackers to evade. In theory, an attacker could generate a unique SSH key pair for every compromised host to prevent recognition of reused keys. In practice, however, this does not scale: managing and distributing thousands of distinct keys across large botnets or long-lived infrastructures would add significant operational complexity. Attackers rely on reusing the same keys across many systems precisely because it is simpler and more manageable. This operational constraint makes the method robust, as it ensures that reused keys leave detectable traces that can be observed at Internet scale.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Because active probing always raises ethical questions, we designed our scans to minimize risks: the probing rate was reduced to be barely noticeable to the sysadmins, authentication was never completed, and only public information was collected. </span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">But detection alone is not enough – compromised machines need to be reported to their operators so they can be cleaned. For that reason, before starting the scans, we partnered with the <b><a href="https://www.shadowserver.org/">Shadowserver Foundation</a> </b>(a nonprofit organization that specializes in large-scale security notifications), and the German Federal CSIRT CERT-BUND to also get notifications about compromised systems to affected parties. Shadowserver and CERT-BUND received the results of our measurements and used its established channels to inform network operators and national CERTs around the world about the affected systems. This ensured that the knowledge we gained was turned into actionable remediation steps without exposing or mishandling sensitive data<a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#reference-4">[4</a>,<a href="https://www.usenix.org/publications/loginonline/catch-22-detecting-compromised-ssh-servers-ssh-public-keys#reference-5">5]</a>.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Follow-up scans conducted after the notifications showed a <b>clear decrease in the number of compromised hosts</b>, demonstrating that the reporting process had a measurable effect. This outcome underlines the importance of linking technical research with operational partners: by combining large-scale measurement with established remediation networks, it is possible not only detect compromised hosts, but also to contribute directly to solving them.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9453"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Conclusion</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">Our work demonstrates that the SSH authentication process itself can be leveraged to detect compromised servers at scale. By focusing on whether a server recognizes known attacker keys, we can detect compromises and with high confidence.</span></span></span></p> <p style="margin-bottom:11px"><span style="font-size:12pt"><span style="line-height:115%"><span style="font-family:Aptos,sans-serif">This method does not aim to replace existing defenses, but it complements them with a tool that is simple, scalable, and precise. Attackers install SSH keys to guarantee their access; that very action can now be turned against them.</span></span></span></p> </div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a><p>[1] Chris Siebenmann. Your SSH keys are a (potential) information leak, 2016. <a href="https://utcc.utoronto.ca/~cks/space/blog/tech/SSHKeysAreInfoLeak">https://utcc.utoronto.ca/~cks/space/blog/tech/SSHKeysAreInfoLeak</a></p> </div><div class="field-item even"><a class="anchor" name="reference-2"></a><p>[2] Artem Golubin. Public SSH keys can leak your private infrastructure, 2019. <a href="https://rushter.com/blog/public-ssh-keys/">https://rushter.com/blog/public-ssh-keys/</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-3"></a><p>[3] <a href="https://edmond.mpg.de/dataset.xhtml?persistentId=doi:10.17617/3.LVPCS6">https://edmond.mpg.de/dataset.xhtml?persistentId=doi:10.17617/3.LVPCS6</a></p> </div><div class="field-item even"><a class="anchor" name="reference-4"></a><p>[4] <a href="https://infosec.exchange/@shadowserver/111840961114655276">https://infosec.exchange/@shadowserver/111840961114655276</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-5"></a><p>[5] <a href="https://www.shadowserver.org/what-we-do/network-reporting/compromised-ssh-host-special">https://www.shadowserver.org/what-we-do/network-reporting/compromised-ss...</a></p> </div><div class="field-item even"><a class="anchor" name="reference-6"></a></div><div class="field-item odd"><a class="anchor" name="reference-7"></a></div><div class="field-item even"><a class="anchor" name="reference-8"></a></div><div class="field-item odd"><a class="anchor" name="reference-9"></a></div><div class="field-item even"><a class="anchor" name="reference-10"></a></div><div class="field-item odd"><a class="anchor" name="reference-11"></a></div><div class="field-item even"><a class="anchor" name="reference-12"></a></div><div class="field-item odd"><a class="anchor" name="reference-13"></a></div><div class="field-item even"><a class="anchor" name="reference-14"></a></div><div class="field-item odd"><a class="anchor" name="reference-15"></a></div><div class="field-item even"><a class="anchor" name="reference-16"></a></div><div class="field-item odd"><a class="anchor" name="reference-17"></a></div><div class="field-item even"><a class="anchor" name="reference-18"></a></div><div class="field-item odd"><a class="anchor" name="reference-19"></a></div><div class="field-item even"><a class="anchor" name="reference-20"></a></div></div></div></div></fieldset>

2025/9/6
阅读更多

eBPF and the Systems Trilemma

<div class="field field-name-field-lv2-subtitle field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Reshaping Operating System Design for Safety, Performance, and Programmability</div></div></div><div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">August 28, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Column</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/ebpf-and-systems-trilemma#Bill%20Mulligan" title="Bill Mulligan">Bill Mulligan</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9429"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">The Enduring Challenge of Operating System Design</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p>Operating system design has long been characterized by inherent trade-offs, often framed as "trilemmas" where optimizing for one critical attribute necessitates compromises in others. This fundamental challenge also echoes across various domains of computer science, like the CAP theorem forcing a choice between consistency, availability, and partition tolerance in distributed systems. These recurring patterns underscore a deeper principle that complex systems frequently face fundamental compromises when striving for multiple desirable characteristics simultaneously.</p> <p>&nbsp;</p> <p>In the realm of operating system programming, a persistent trilemma has historically revolved around Safety, Performance, and Programmability. Achieving an optimal equilibrium across these three crucial attributes has presented a significant hurdle, forcing developers and architects into difficult choices between them.</p> <p>&nbsp;</p> <p>Safety encompasses the system's stability, security, and resilience against errors, vulnerabilities, or malicious actions, including memory safety, fault tolerance, and effective recovery mechanisms. Performance refers to the speed, efficiency, and resource utilization of operations, aiming to minimize latency, maximize throughput, and optimize CPU and memory consumption. Programmability denotes the ease with which new features or functionalities can be developed, deployed, and adapted, covering development complexity, debugging ease, dynamic extensibility, and compatibility across system versions.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9430"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/ynq0Pe76jhWlzgB1c6TwLW5FOXy_aVl-CIT7epCWrxU/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9jZW50cmFsaXplX3RvX2RlY2VudHJhbGl6ZWRfaW50ZWxsaWdlbmNlMnhfOS5wbmc" width="1016" height="944" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Fig. 1: CAP Theorem showcases the system trilema</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9431"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Programmability with Kernel Modules and User-Space Agents</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p dir="ltr">Before eBPF, extending kernel functionality, without upstream changes, typically involved either kernel modules or user-space agents. Each enabled programmability, but also presented its own set of trade-offs with safety and performance.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9432"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Kernel Modules: Power with Peril</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p dir="ltr">Kernel modules are object files containing code designed to extend the kernel's functionality at runtime. They can be loaded and unloaded as needed, providing a solution to the inherent lack of extensibility in traditional monolithic kernels. Operating directly within kernel space, these modules possess full and unrestricted access to kernel internals and hardware. This deep integration makes them suitable for tasks demanding low-level control, such as implementing device drivers or dynamically adding new kernel features.</p> <p dir="ltr">The key advantage of kernel modules is performance because of their direct integration with the kernel. However, this pursuit of performance often comes at the cost of system safety. A single mistake or bug in a kernel module can lead to severe system instability, including blocking the entire system or even a "kernel panic" (a fatal error requiring a system reboot) as showcased by the <a href="https://www.theregister.com/2024/07/19/crowdstrike_shares_sink_as_global/" target="_blank">CrowdStrike incident</a> that took down IT systems worldwide. Kernel module’s unrestricted access means a poorly written or malicious one can compromise the entire system, posing significant safety and security vulnerabilities.</p> <p dir="ltr">Furthermore, the practical realities of developing and deploying kernel modules reveal significant rigidity. Compiling kernel modules is non-trivial; they require specific kernel headers and must be compiled with the exact same options as the kernel they are intended for. Deployment is also cumbersome, as modules often need to be built against specific kernel versions. While a simple module can be loaded and unloaded with a command like modprobe without a reboot, applying security patches or other critical updates to the kernel often necessitates a full system reboot to ensure the changes are applied safely and the system remains stable. System reboots can also be necessary during troubleshooting, which severely slows down the development cycles.</p> <p dir="ltr">This rigidity makes modern practices like live patching impossible for customized kernels, unlike standard ones. Maintaining custom kernels manually is a complex task requiring considerable in-house expertise for applying security patches, recompiling customizations after updates, and rigorous testing before deployment. Thus, the "flexibility" offered by kernel modules comes with a significant hidden cost in terms of operational friction, development overhead, and potential system downtime, making it difficult to leverage in dynamic, high-availability environments.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9433"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/7EmyzQIJKVk6Lrlf2x_qHae1tvBJdAr8SWjOEqW7wVs/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9jZW50cmFsaXplX3RvX2RlY2VudHJhbGl6ZWRfaW50ZWxsaWdlbmNlMnhfMTAucG5n" width="1016" height="944" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 2. Kernel modules trade-off safety for performance and programmability</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9434"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">User-Space Agents: Safe but Slow</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p dir="ltr">User-space agents are traditional applications that operate in "user mode," a sandboxed environment purposefully isolated from the kernel. To access kernel-provided services or low-level system data, user-space programs must interact with the kernel via Userspace Application Programming Interfaces (UAPIs), primarily through system calls. This bifurcated architecture is fundamental to isolating ordinary programs from the kernel, ensuring that a buggy program does not crash the entire system. This isolation also means that a malicious user program cannot directly compromise the kernel to, for example, hide processes or grant unauthorized access. These agents are commonly employed for various system-level tasks, including monitoring, logging, performance analysis, and security auditing.</p> <p dir="ltr">The primary benefit of user-space agents is their inherent safety. Because they are sandboxed and operate in user space, a buggy or malicious program is prevented from crashing the entire system or accessing sensitive kernel data directly. This isolation makes the system more resilient to application crashes.</p> <p dir="ltr">However, the very mechanism that ensures safety in user-space agents, their isolation from the kernel, is also the primary cause of their performance limitations. The most significant bottleneck is the frequent context switching between kernel space and user space required every time they need to access kernel-level data or services via system calls. This constant switching incurs substantial overhead and introduces significant latency. Traditional monitoring agents, by requesting data from the kernel, incur a processing overhead and consume more memory and CPU resources compared to in-kernel execution. Compounding this, recent security mitigations for vulnerabilities like Spectre and Meltdown have unfortunately made syscalls even slower, further degrading performance. This direct causal link between safety mechanisms and performance degradation highlights a dilemma where prioritizing safety through strict isolation compromises efficiency, making such systems impractical for many modern, high-performance applications.</p> <p dir="ltr">Beyond performance, user-space agents introduce considerable operational challenges. Agent-based monitoring solutions can consume valuable system resources, including CPU, memory, and network bandwidth, potentially impacting the performance of the applications they are monitoring. Data collection by user-space agents is inherently limited to what they can observe from their isolated user-space perspective. In modern cloud native architectures where ephemeral workloads can come and go quickly, the lifecycle of a container can be shorter than the time required for a user-space monitoring agent to fully deploy and initialize, making effective monitoring impossible.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9435"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/aAzP6d2Zlv0cz6AFMGaez0j9UfEqhlH4zdUFEVe2Ex4/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9jZW50cmFsaXplX3RvX2RlY2VudHJhbGl6ZWRfaW50ZWxsaWdlbmNlMnhfMTEucG5n" width="1016" height="944" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 3. User space agents get safety, but give up their performance edge</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9436"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">The eBPF Revolution: Solving the Trilema</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p dir="ltr">eBPF is highly flexible and programmable and allows safe and efficient execution of user-defined programs directly within the Linux kernel. It operates by attaching small, event-driven programs to various kernel hooks, such as system calls, tracepoints, network events, kprobes (kernel probes), and uprobes (user-space probes). These programs execute upon specific triggers, such as packet reception or a kernel function call.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9437"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">eBPF Architecture and Core Mechanisms</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p dir="ltr">eBPF’s architecture is built upon several key components that collectively enable its unique capabilities:</p> <ul> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation">Hook Points: eBPF programs are event-driven and require a "hook point" to execute. These hooks are locations in the kernel or in user-space applications that trigger the eBPF program to run, allowing for highly granular and dynamic instrumentation. Predefined hook points are available for common events like system calls, kernel tracepoints, and network events. For custom needs, developers can create a kernel probe (kprobe) or a user probe (uprobe) to attach eBPF programs almost anywhere. A uprobe is a mechanism to dynamically instrument a function or routine within a user-space application. When triggered, a traditional uprobe enters the kernel and executes the eBPF program, which requires two context switches, one into the kernel and one back out. This process can introduce significant overhead, similar to the performance bottleneck faced by user-space agents. To address this, the eBPF community is developing new solutions, such as user-space eBPF runtimes like bpftime, which bypass the context switches entirely by running the eBPF program in user space.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation">Restricted Execution Environment: eBPF programs run in a restricted virtual machine within the kernel. This restricted&nbsp;environment is crucial for ensuring safe execution and minimizing the risk of kernel crashes or instability, providing a clear advantage over traditional kernel modules.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation">Verifier: Before any eBPF program can run, it undergoes a rigorous verification process by the in-kernel BPF verifier. The verifier checks for potential issues, such as attempts to access memory outside designated regions, guarantees program termination (for example by forbidding loops), performs strict type checks on helper function arguments, and ensures buffer initialization. The verifier is central to eBPF's safety guarantees.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation">JIT Compiler (Just-In-Time): If the program successfully passes verification, the kernel's Just-In-Time (JIT) compiler converts the eBPF bytecode into native machine code optimized for the underlying CPU architecture. This JIT compilation significantly speeds up execution by reducing the per-instruction cost and often mapping BPF instructions one-to-one with native instructions, improving CPU instruction cache friendliness.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation">Maps: eBPF programs can utilize efficient key/value stores called maps, which reside in kernel space. These maps allow eBPF programs to maintain state across invocations and communicate with user-space applications. Maps can also be shared among different eBPF programs, enabling complex interactions and data exchange.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation">Helper Functions: eBPF programs can invoke a set of <b>bpf_helper</b> kernel functions, which provide access to common kernel functionalities like memory copying, retrieving process IDs (PIDs), timestamps, and interacting with maps.</p> </li> <li aria-level="1" dir="ltr"> <p dir="ltr" role="presentation">Tail Calls: Allows one eBPF program to call another eBPF program, enabling modularity and the creation of more complex, chained logic without returning to user space.</p> </li> </ul> <p>A more in depth history and architectural overview can be found <a href="https://www.usenix.org/system/files/login/articles/login_spring18_05_choudhury.pdf">here</a>.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9438"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">eBPF's Balanced Approach to the Trilemma</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p dir="ltr">eBPF achieves kernel-level performance with enhanced safety and programmability without kernel modification through a unique combination of these mechanisms. By executing directly within the kernel space, eBPF programs eliminate the need for costly user-kernel context switches and syscalls that burden user-space agents. This direct access to kernel-level resources and system data enables high performance.</p> <p dir="ltr">The eBPF verifier is the cornerstone of eBPF's safety model. It guarantees that programs are safe, terminate, and cannot destabilize the system. The trust through verification approach represents a fundamental shift in how privileged system components can be extended safely and dynamically. The JIT compiler further optimizes eBPF bytecode into highly efficient native machine code, ensuring that programs run with minimal overhead and near-native speed.</p> <p dir="ltr">Finally, a key advantage for programmability is the ability to dynamically load and unload eBPF programs without requiring system reboots. This allows for real-time updates to monitoring, security, or networking logic without service interruption which represents a fundamental shift from the rigid, static, compile-time approach of kernel modules to a truly dynamic, runtime approach.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9439"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/ywTyZORNnI5Mep43z941fCWqtkXbPCH1mq2L5lav7pE/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9jZW50cmFsaXplX3RvX2RlY2VudHJhbGl6ZWRfaW50ZWxsaWdlbmNlMnhfOC5wbmc" width="944" height="824" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 4. eBPF allows developers to balance safety, performance, and programmability in the kernel</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9440"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Conclusion: A New Era of Kernel Programmability</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p dir="ltr">eBPF represents a profound shift in operating system design, fundamentally overcoming the traditional Systems Trilemma by providing an unparalleled balance of Safety, Performance, and Programmability. It successfully "threads the needle" where previous technologies, such as kernel modules and user-space agents, were forced into difficult compromises. Kernel modules offered raw performance but at significant risk to system stability and with high development complexity. User-space agents provided safety and ease of development but suffered from substantial performance overhead due to constant user-kernel context switching.</p> <p dir="ltr">eBPF's innovative architecture, featuring an in-kernel verifier, Just-In-Time compilation, and a sandboxed execution environment, enables kernel-speed execution with robust safety guarantees. Its dynamic loading capabilities and rich tooling ecosystem provide programmability and flexibility, allowing for real-time system introspection and modification without kernel recompilation or reboots. The ideas behind eBPF are changing how we think about system-level programming.</p> <p dir="ltr">eBPF has democratized access to kernel-level control, allowing a broader range of developers to innovate safely within the kernel. Furthermore, eBPF's ability to provide rich, real-time, low-overhead data positions it as a foundational technology for building truly intelligent, responsive, and self-optimizing infrastructure. As the technology continues to evolve and its ecosystem matures, eBPF is poised to reshape how complex computing systems are designed, built, and operated for years to come.</p> <p>&nbsp;</p> <p dir="ltr">Where to learn more about eBPF:</p> <p dir="ltr"><a href="https://ebpf.io/what-is-ebpf/" target="_blank">What is eBPF?</a></p> <p dir="ltr"><a href="https://www.youtube.com/watch?v=Wb_vD3XZYOA" target="_blank">eBPF Documentary</a></p> <p dir="ltr"><a href="https://cilium.isovalent.com/hubfs/Learning-eBPF%20-%20Full%20book.pdf" target="_blank">Learning eBPF eBook</a></p> <p dir="ltr"><a href="https://ebpf.io/applications/" target="_blank">eBPF Landscape</a></p> <p dir="ltr"><a href="https://ebpf.foundation/" target="_blank">eBPF Foundation</a></p> </div></div></div> </div> </div> </div></div></div></div> <div class="field field-name-field-lv2-pdf field-type-file field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="file"><img class="file-icon" alt="PDF icon" title="application/pdf" src="https://imgproxy.citrusreader.com/Gdj_AqbXYoQ5zo3KqXytAG5JqQBZliwVR3mizNRudxo/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9jb3JlL21vZHVsZXMvZmlsZS9pY29ucy9hcHBsaWNhdGlvbi1wZGYucG5n" referrerpolicy="no-referrer"> <a href="https://www.usenix.org/sites/default/files/ebpf_and_the_systems_trilemma__reshaping_operating_system_design_for_safety_performance_and_programmability.pdf" type="application/pdf; length=479043" title="ebpf_and_the_systems_trilemma__reshaping_operating_system_design_for_safety_performance_and_programmability.pdf">Download PDF</a></span></div></div></div><fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a></div><div class="field-item even"><a class="anchor" name="reference-2"></a></div><div class="field-item odd"><a class="anchor" name="reference-3"></a></div><div class="field-item even"><a class="anchor" name="reference-4"></a></div><div class="field-item odd"><a class="anchor" name="reference-5"></a></div><div class="field-item even"><a class="anchor" name="reference-6"></a></div></div></div></div></fieldset>

2025/8/27
阅读更多

Toward Practical and Usable Provenance-based Intrusion Detection Systems

<div class="field field-name-field-lv2-subtitle field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">A closer look at the practical value of provenance-based intrusion detection systems.</div></div></div><div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">August 27, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Research</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#Tristan%20Bilot" title="Tristan Bilot">Tristan Bilot</a>, <a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#Thomas%20Pasquier" title="Thomas Pasquier">Thomas Pasquier</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9407"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">In recent years, researchers have turned to provenance-based intrusion detection systems (<strong>PIDSs</strong>) as a promising way to spot attacks that evade past traditional defenses. At their core, these systems build <strong>provenance graphs</strong>, which act like detailed maps of how information flows through a computer. Such graphs treat system entities (e.g., processes, files, and network connections) as nodes, and the interactions between them (e.g., system calls) as edges. By analyzing these graphs, anomaly-based PIDSs learn what "normal" behavior looks like and then flag unusual activity, making them well-suited for catching stealthy attacks such as advanced persistent threats (<strong>APTs</strong>) or previously unknown <strong>zero-day</strong> exploits.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Despite claims of near-perfect detection rates, today's PIDSs are <em><strong>nowhere near ready for real-world use</strong></em>. Their biggest flaw is how they report results: most state-of-the-art PIDSs generate coarse-grained alerts with tens of thousands of nodes or events, burying analysts under mountains of noise. This is not just an engineering oversight; it is the direct result of evaluation practices. By optimizing for specific evaluation metrics instead of usable outputs, the community has built detectors that are impressive on paper but fall short of being helpful to a security team.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Our research also exposes deeper flaws in how current systems are designed and evaluated. This comes in the way of industry adoption<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-6">[6]</a>. Even when working from the same datasets, different studies use their own training and testing splits, preprocessing pipelines, and labeling strategies. These inconsistencies, common across many ML-driven fields<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-9">[9]</a>, fragment evaluation and make it impossible to compare competing methods fairly</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-callout paragraphs-item-callout paragraphs-item-full paragraphs-item-9422"> <div class="content"> <div class="field field-name-field-callout-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p><span lang="EN" style="font-size:11.0pt" xml:lang="EN"><span style="line-height:115%"><span style="font-family:&quot;Arial&quot;,sans-serif">This article summarizes our recent efforts to address these challenges, drawing on two papers<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-3">[3]</a>,<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-4">[4]</a> presented at USENIX Security 2025.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9408"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">The Need for High Quality of Attribution</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="border:none"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Evaluating a PIDS typically involves measuring detection quality in terms of true and false positives. However, we find that many state-of-the-art systems do not optimize for Quality of Attribution (QoA): the effort a human analyst must expend to interpret alerts, trace an attack’s root cause, assess its impact, and dismiss false positives. In practice, prior work often produces<strong> massive volumes of low-QoA output</strong>, much of it irrelevant to actual attack activity. The result is predictable: <strong>noisy reports</strong> that overwhelm analysts, fueling alert fatigue <a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-1">[1]</a> and, ultimately, burnout <a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-2">[2]</a>.</span></span></span></p> <p style="border:none"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">We identified three main evaluation strategies used in assessing state-of-the-art systems.</span></span></span></p> <p style="border:none"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Neighborhood Approach</b>: Labels all nodes within two hops of the ground truth nodes as malicious. This pulls in benign nodes that only share dependencies with attack events, leading to overestimation.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Batch Approach</b>: Groups events into fixed-size or time-based batches and assigns anomaly scores per batch. Benign events occurring alongside attacks are often flagged, inflating results.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Source Approach</b>: Labels all descendants of identified source nodes as malicious. This exaggerates attack scope: for example, normal activity after a process hijack is also marked malicious.</span></span></span></p> <p style="border:none"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Although systems built under these evaluation strategies may seem effective at flagging anomalies associated with attacks, they fall short when it comes to accurate node-level attribution. Prior work <a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-7">[7]</a>, <a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-8">[8]</a> has acknowledged this gap, emphasizing the challenge posed by the overwhelming volumes of data that state-of-the-art PIDSs generate and the burden this places on security analysts.</span></span></span></p> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Our approach</b>:<b> </b>We undertook a painstaking manual analysis of the datasets, cross-checking the textual documentation against the actual data to pinpoint the specific nodes involved in each attack. Whereas prior work labeled thousands of nodes as malicious, our analysis revealed that the true number is far smaller—between 41 and 123 nodes, as shown in Figure 1.</span></span></span></p> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">By shifting the evaluation focus to the quality of attribution, we encourage the development of systems that deliver far more helpful results. Instead of rewarding detectors that flood analysts with thousands of noisy alerts, this approach promotes systems that highlight a small set of high-quality attack nodes containing the actual malicious payloads, outputs that analysts can act on directly.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9409"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/S1rtM0MUM8o6hhboX02x4iwwYyW1vJfq8cX1HisruUE/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9wbG90LnBuZw" width="1440" height="593" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 1. Number of malicious nodes reported by each evaluation strategy, on DARPA TC datasets.</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9410"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Achieving High Quality of Attribution</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Most existing systems look good on paper but fall short when analysts need fine-grained answers. Under our node-level evaluation, they simply aren’t designed to deliver the precision required. This gap led us to build <b>Orthrus</b>, a PIDS tailored for the job. Orthrus combines temporal graph learning with causality analysis to do two things analysts care about most: (1) detect node-level anomalies without relying on prior attack knowledge, and (2) reconstruct clear attack scenarios. Instead of drowning analysts in noise, Orthrus generates concise, high-quality summary graphs that spotlight the malicious activity. The result is less time wasted on irrelevant alerts and more time spent understanding real threats. As Figure 2 shows, Orthrus achieves this through five coordinated components.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Graph Construction:</b> Provenance graphs are built from raw system logs, with redundant edges pruned while preserving event order.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Edge Featurization:</b> Graphs are transformed into sequences of vectorized edges by transforming the textual attributes of entities into text embeddings using <strong>word2vec</strong>. These embeddings aim to embed entities with similar semantics closer in embedding space, and are used as node features in the graph.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Temporal Graph Learning:</b> An encoder-decoder architecture captures structural and temporal patterns. The encoder computes node embeddings by gathering the last activity of nodes and aggregating neighbor information with an attention-based graph neural network (GNN). The decoder passes node embeddings in an additional neural network and the model is trained end-to-end to predict system call types between connected nodes from benign activity. The resulting reconstruction loss serves as an anomaly score to assess malicious activity.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Anomaly Detection:</b> Malicious nodes are detected by thresholding and clustering. The threshold is automatically computed as the maximum loss encountered on the validation set. The flagged nodes are subsequently separated in two clusters with K-Means, with the top-cluster selected as reported attack nodes.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Attack Reconstruction:</b> Detected nodes are used in an attack reconstruction step, aiming to uncover more nodes by causality analysis from the graph structure and predicted scores&nbsp;<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-10">[10]</a>. Orthrus finally reports concise summary graphs representing the predicted attack path.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9411"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/90zaYR3uMPg7CQ4eqJMnClpv1A-29WvPnEXRHAKPhRw/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9vcnRocnVzLnBuZw" width="1440" height="949" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 2. Architecture of Orthrus.</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9412"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><h3><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b><span lang="EN" style="font-size:14.0pt" xml:lang="EN"><span style="line-height:115%">Evaluation of Orthrus</span></span></b></span></span></span></h3> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">We evaluate Orthrus (Figure 3) against five state-of-the-art baselines using our node-level strategy on six DARPA TC datasets, tuning all baselines consistently through grid search on key hyperparameters.</span></span></span></p> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">We benchmark two variants of Orthrus:</span></span></span></p> <ul> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Orthrus-full</b>: full Orthrus pipeline as shown in Figure 2.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Orthrus-ano</b>: Orthrus pipeline without the attack reconstruction step.</span></span></span></li> </ul> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Overall, <b>Orthrus-ano</b> reliably detects at least one node per attack across all datasets, while producing fewer false positives than baseline methods. Indeed, a practical system must minimize false positives (i.e., ensure high precision) as long as all attacks are detected, rather than focusing on identifying every single node involved in an attack (i.e., high recall)&nbsp;<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-6">[6]</a>. </span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Orthrus-full</b> builds upon Orthrus-ano’s output to recover additional true positives. It successfully enhances attribution while maintaining a low false positive rate, providing a complementary output that analysts can leverage for deeper investigation.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9413"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/5OOykD5hmsA59HnVMCcZLPZ7jcEMf-p7uHbjnwuUYWo/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy90YWJsZXMucG5n" width="1440" height="564" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 3. Node-level detection results of Orthrus and baselines.</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9414"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Toward More Practical Systems</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Although Orthrus marks progress toward practical detection by substantially reducing analyst workload through concise reports, this system and other recent approaches still face limitations that hinder real-world deployment. The practicality and usability of PIDSs should matter as much as detection accuracy for real-world adoption. To move the field forward, system design must <strong>prioritize analyst needs</strong> so that research prototypes evolve into tools that are truly deployable, rather than remaining academic exercises.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">In particular, real-time detection remains challenging, as it would require running inference on the provenance graph after every incoming edge, an approach that does not scale with increasing numbers of hosts. One way to address this challenge is to significantly <strong>simplify the architecture</strong>, avoiding heavy models such as GNNs. However, many recent works neglect to compare their systems against simpler baselines, instead favoring evaluations only against equally complex, state-of-the-art approaches.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Motivated by this gap, we developed a <strong>unified framework</strong> that re-implements eight state-of-the-art PIDSs published in top-tier security venues. The framework is modularized to support combinatorial exploration of architectural components, enabling systematic benchmarking of performance across models of varying complexity.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Through this exploration, we experimented with each PIDS and identified several limitations in their design and evaluation strategies. We distill these into <b>nine key shortcomings</b> that, in our view, must be addressed for the community to develop and publish more practical systems.</span></span></span></p> <ol> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Insufficient Detection Granularity</b>: As demonstrated in Orthrus, most systems detect attacks at the graph or neighborhood levels, leading to thousands elements to analyze.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Missing Metric to Measure Attack Detection</b>: Traditional metrics don’t account for individual attacks and are biased toward thresholding: Systems rely on fixed, arbitrary and manually set thresholds that fail to adapt dynamically.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Impractical Thresholding Methods</b>: Systems rely on fixed, arbitrary and manually set thresholds that fail to adapt dynamically.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Unfair Comparison with Baselines</b>: Evaluation baselines are left untuned, while proposed systems are typically extensively tuned.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Not Measuring Instability</b>: The detection performance of systems is extremely unstable under identical configurations.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Featurization Methods Trained on Test Data</b>: Some systems train on test data, leading to data snooping by exploiting information that would be unavailable in practice.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Overly Complex Architectures</b>: Systems are usually complex, yet they are rarely compared to much simpler models.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Insufficient Scalability</b>: Systems do not meet scalability and overhead requirements for a practical deployment.</span></span></span></li> <li><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Lacking Real-Time Detection</b>: Systems are poorly fitted for real-time setting due to their design and overhead.</span></span></span></li> </ol> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Some shortcomings (1–6) can be addressed within existing PIDSs through more thorough experimentation or simple architecture modifications. In contrast, the last three (7–9) reflect deeper structural issues that result in overly complex architectures with poor scalability and limited support for real-time detection.</span></span></span></p> <h3 style="margin-top: 16px; margin-bottom: 16px;"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><span lang="EN" style="font-size:18.0pt" xml:lang="EN"><span style="line-height:115%">Exploring Simpler and Lightweight Architectures</span></span></span></span></span></h3> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">To investigate simpler variants, we conducted extensive experiments totaling more than 453 days of computation on servers equipped with modern GPUs. We explored a range of new architectures by combining components from existing PIDSs and performing ablations to assess the impact of removing specific components. All variants were compared against existing PIDS baselines, with hyperparameters tuned and the best models selected for evaluation on nine DARPA TC and OpTC datasets simulating APT campaigns. Performance was assessed using attack detection precision (ADP), a pre-threshold metric that captures the ability to detect all attacks while maintaining high precision.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Surprisingly, our results show that a <b>much simpler architecture</b> not only <b>matches</b> <b>their</b> <b>performance</b> but does so with significantly lower runtime and memory overhead.</span></span></span></p> <p><span lang="EN" style="font-size:11.0pt" xml:lang="EN"><span style="line-height:115%"><span style="font-family:&quot;Arial&quot;,sans-serif">This variant, illustrated in Figure 4 and referred to as <b>Velox</b>, is a lightweight alternative to heavyweight GNNs and addresses all identified shortcomings by design. When processing an edge, it embeds the textual attributes of the source and destination nodes (file paths, process command lines, and socket IP addresses) using <strong>word2vec</strong>. These embeddings are then passed to a small neural network trained to predict the system call type associated with each edge. The prediction loss becomes the anomaly score, with nodes connected to high-scoring edges flagged as anomalous. Detection is performed through automatic thresholding calibrated on the validation set.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9415"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/ci4Tb1ynK9bO6Fcjoimo7Rqv5dmHYkhCnrm1n0UlEYw/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9hcmNoaS5wbmc" width="1440" height="353" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 4. Neural network architecture of Velox.</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9416"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Figure 5 shows ADP performance alongside runtime and memory usage on the E3-CADETS dataset, which contains three attacks (results are equivalent on other datasets).<br> In simple terms, ADP balances detection coverage with alert reliability. Formally, it is the area under the detected-attacks–precision curve, with ADP = 1 when all attacks are found with perfect precision, and ADP = 0 when detection occurs only at near-zero precision.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9417"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/A3RAWCAJXa65KS5ObhdGjalsQJ2x7tYQMMamON-6sPM/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9hZHAucG5n" width="1440" height="342" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Figure 5. Attack detection precision versus time and memory. Velox and Orthrus are represented by the black and dark-blue nodes, respectively, while other colors denote the benchmarked PIDS baselines.</div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9418"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">At the node level, only Orthrus and Velox <strong>detect all attacks</strong> with high precision, reflected in their near-perfect ADP scores. The key difference is efficiency: Velox delivers the same detection capability as Orthrus but with <strong>far lower cost</strong>. This proves that, in this domain, simplicity can outperform complexity.</span></span></span></p> <blockquote> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">These findings are surprising and raise an important question about the growing complexity of PIDS architectures: <b><i>is such complexity always necessary?</i></b></span></span></span></p> </blockquote> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">We did not expect APT attacks to be detected so effectively using only the textual attributes of system entities. To avoid unnecessary complexity, we advocate for advanced ablation studies that empirically demonstrate that the only way to achieve such performance across multiple datasets is through integrating all components proposed in the paper.&nbsp;</span></span></span><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Otherwise, simpler variants may exist but remain unexplored.</span></span></span></p> <blockquote> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">These results raise another important question: <b><i>are the DARPA TC and OpTC datasets truly realistic benchmarks?</i></b> </span></span></span></p> </blockquote> <p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">Recent work<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-5">[5]</a> points out that these datasets include synthetic benign background activity, which artificially inflates true negative rates, while overly conspicuous malicious events inflate true positives. As a result, they reward systems for solving an easier problem than what analysts face in practice. Developing datasets that more accurately capture the messiness of real-world environments is, therefore, essential if we want PIDS evaluations in the literature to reflect genuine progress.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9419"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">A Unified Framework to Support Future Research</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">To support the community, we are releasing <b>PIDSMaker</b><a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-11">[11]</a>,<a href="https://www.usenix.org/publications/loginonline/toward-practical-and-usable-provenance-based-intrusion-detection-systems#reference-3">[3]</a>, an open-source framework that unifies eight state-of-the-art systems into a single execution pipeline optimized for modularity and computational reuse. PIDSMaker was the foundation for the evaluations in both of our papers, and we hope it will serve as a common platform for future research, enabling consistent benchmarking and lowering the barrier to developing new systems.</span></span></span></p> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">PIDSMaker’s pipeline (Figure 7) is organized into modular tasks, each with its own arguments. Every PIDS is specified in a YAML file that consolidates all relevant parameters, making configurations easy to manage and reproduce. Intermediate outputs are cached locally and indexed by a hash of the current and preceding task arguments, ensuring that previously computed results are not recomputed.</span></span></span></p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-article-image paragraphs-item-article-image paragraphs-item-full paragraphs-item-9420"> <div class="content"> <div class="field field-name-field-article-image field-type-image field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><img src="https://imgproxy.citrusreader.com/eBbwxoQlwcca3iAU7bqzwO_bVxnhpyqvCuVaFpUae88/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL3N0eWxlcy9hcnRpY2xlX2VtYmVkZGVkL3B1YmxpYy9waXBlbGluZV8xLnBuZw" width="1440" height="242" alt referrerpolicy="no-referrer"></div></div></div><div class="field field-name-field-article-image-caption field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">PIDSMaker framework’s pipeline.</div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9421"> <div class="content"> <div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">The framework supports a variety of features.</span></span></span></p> <ul style="margin-bottom:16px"> <li style="margin-left:8px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Combinatorial exploration of components: </b>The framework modularizes components from all baseline systems into ready-to-use building blocks, enabling flexible combinations. This design supports the creation of new PIDS variants by mixing and matching different encoders, decoders, training objectives, and thresholding strategies.</span></span></span></li> <li style="margin-left:8px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Consistent Evaluation:</b> All baselines share a common backbone and preprocessing pipeline, and are evaluated against the same ground truth, ensuring fair and consistent comparisons.</span></span></span></li> <li style="margin-left:8px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Hyperparameter Tuning:</b> Since PIDSs are highly sensitive to hyperparameter choices, the framework includes a unified tuning module to ensure consistent optimization across all baselines.</span></span></span></li> <li style="margin-bottom:16px; margin-left:8px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif"><b>Instability Measurement:</b> PIDSs often produce variable results across runs. The framework supports repeated executions and quantifies instability using standard deviation metrics, providing a robust measure of variance.</span></span></span></li> </ul> <p style="margin-top:16px; margin-bottom:16px"><span style="font-size:11pt"><span style="line-height:115%"><span style="font-family:Arial,sans-serif">We welcome researchers to contribute their systems to PIDSMaker and join us in extending and keeping the framework up to date.</span></span></span></p> </div></div></div> </div> </div> </div></div></div></div> <div class="field field-name-field-lv2-pdf field-type-file field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="file"><img class="file-icon" alt="PDF icon" title="application/pdf" src="https://imgproxy.citrusreader.com/Gdj_AqbXYoQ5zo3KqXytAG5JqQBZliwVR3mizNRudxo/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9jb3JlL21vZHVsZXMvZmlsZS9pY29ucy9hcHBsaWNhdGlvbi1wZGYucG5n" referrerpolicy="no-referrer"> <a href="https://www.usenix.org/sites/default/files/2025-login.pdf" type="application/pdf; length=1704748" title="2025-login.pdf">Download PDF</a></span></div></div></div><fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a><p>[1] Hassan, Wajih Ul, et al. "Nodoze: Combatting threat alert fatigue with automated provenance triage." Network and Distributed Systems Security Symposium. 2019.</p> </div><div class="field-item even"><a class="anchor" name="reference-2"></a><p>[2] Sundaramurthy, Sathya Chandran, et al. "A human capital model for mitigating security analyst burnout." Symposium on Usable Privacy and Security (SOUPS 2015). 2015.</p> </div><div class="field-item odd"><a class="anchor" name="reference-3"></a><p>[3] Bilot, Tristan, et al. "Sometimes Simpler is Better: A Comprehensive Analysis of State-of-the-Art Provenance-Based Intrusion Detection Systems." USENIX Security Symposium. 2025.</p> </div><div class="field-item even"><a class="anchor" name="reference-4"></a><p>[4] Jiang, Baoxiang, et al. "ORTHRUS: Achieving High Quality of Attribution in Provenance-based Intrusion Detection Systems." USENIX Security Symposium. 2025.</p> </div><div class="field-item odd"><a class="anchor" name="reference-5"></a><p>[5] Liu, Jason, et al. "What We Talk About When We Talk About Logs: Understanding the Effects of Dataset Quality on Endpoint Threat Detection Research." IEEE Symposium on Security and Privacy. 2025.</p> </div><div class="field-item even"><a class="anchor" name="reference-6"></a><p>[6] Dong, Feng, et al. "Are we there yet? an industrial viewpoint on provenance-based endpoint detection and response tools." ACM Conference on Computer and Communications Security. 2023.</p> </div><div class="field-item odd"><a class="anchor" name="reference-7"></a><p>[7] Cheng, Zijun, et al. "Kairos: Practical intrusion detection and investigation using whole-system provenance." IEEE Symposium on Security and Privacy. 2024.</p> </div><div class="field-item even"><a class="anchor" name="reference-8"></a><p>[8] Rehman, Mati Ur, Hadi Ahmadi, and Wajih Ul Hassan. "Flash: A comprehensive approach to intrusion detection via provenance graph representation learning." IEEE Symposium on Security and Privacy. 2024.</p> </div><div class="field-item odd"><a class="anchor" name="reference-9"></a><p>[9] Arp, Daniel, et al. "Dos and don'ts of machine learning in computer security." USENIX Security Symposium. 2022.</p> </div><div class="field-item even"><a class="anchor" name="reference-10"></a><p>[10] Fang, Pengcheng, et al. "Back-Propagating system dependency impact for attack investigation." USENIX Security Symposium. 2022.</p> </div><div class="field-item odd"><a class="anchor" name="reference-11"></a><p>[11] <a href="https://github.com/ubc-provenance/PIDSMaker">https://github.com/ubc-provenance/PIDSMaker</a></p> </div><div class="field-item even"><a class="anchor" name="reference-12"></a></div><div class="field-item odd"><a class="anchor" name="reference-13"></a></div><div class="field-item even"><a class="anchor" name="reference-14"></a></div><div class="field-item odd"><a class="anchor" name="reference-15"></a></div><div class="field-item even"><a class="anchor" name="reference-16"></a></div><div class="field-item odd"><a class="anchor" name="reference-17"></a></div><div class="field-item even"><a class="anchor" name="reference-18"></a></div><div class="field-item odd"><a class="anchor" name="reference-19"></a></div><div class="field-item even"><a class="anchor" name="reference-20"></a></div><div class="field-item odd"><a class="anchor" name="reference-21"></a></div><div class="field-item even"><a class="anchor" name="reference-22"></a></div><div class="field-item odd"><a class="anchor" name="reference-23"></a></div><div class="field-item even"><a class="anchor" name="reference-24"></a></div><div class="field-item odd"><a class="anchor" name="reference-25"></a></div><div class="field-item even"><a class="anchor" name="reference-26"></a></div><div class="field-item odd"><a class="anchor" name="reference-27"></a></div><div class="field-item even"><a class="anchor" name="reference-28"></a></div><div class="field-item odd"><a class="anchor" name="reference-29"></a></div><div class="field-item even"><a class="anchor" name="reference-30"></a></div><div class="field-item odd"><a class="anchor" name="reference-31"></a></div><div class="field-item even"><a class="anchor" name="reference-32"></a></div><div class="field-item odd"><a class="anchor" name="reference-33"></a></div><div class="field-item even"><a class="anchor" name="reference-34"></a></div><div class="field-item odd"><a class="anchor" name="reference-35"></a></div><div class="field-item even"><a class="anchor" name="reference-36"></a></div><div class="field-item odd"><a class="anchor" name="reference-37"></a></div></div></div></div></fieldset>

2025/8/26
阅读更多

SecSRE: Bringing Security into the SRE World

<div class="field field-name-field-lv2-publication-date field-type-datetime field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><span class="date-display-single">August 25, 2025</span></div></div></div><div class="field field-name-field-lv2-article-type field-type-taxonomy-term-reference field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Opinion</div></div></div><div class="field field-label-inline clearfix field-type-text-long field-pseudo-field field-pseudo-field--author-list"><div class="field-label">Authors:&nbsp;</div><div class="field-items"><a href="https://www.usenix.org/publications/loginonline/secsre-bringing-security-sre-world#Sabitha%20Muppuri" title="Sabitha Muppuri">Sabitha Muppuri</a>, <a href="https://www.usenix.org/publications/loginonline/secsre-bringing-security-sre-world#Sangharsh%20Agarwal" title="Sangharsh Agarwal">Sangharsh Agarwal</a></div></div><div class="field field-name-field-lv2-shepherds field-type-user-reference field-label-inline clearfix"><div class="field-label">Article shepherded by:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><span class="usenix-user-reference-names">Rik Farrow</span></div></div></div> <div class="paragraphs-items paragraphs-items-field-lv2-body paragraphs-items-field-lv2-body-full paragraphs-items-full"> <div class="field field-name-field-lv2-body field-type-paragraphs field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9394"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">SecSRE: Bringing Security into the SRE World</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; margin: 20px 0;"><em>“Security is a reliability problem.”</em><br> <span style="font-weight: bold; color: black; text-decoration: none;">– Common wisdom in modern DevSecOps culture </span></p> <p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; margin: 20px 0;">Site Reliability Engineering (SRE) is about keeping systems fast, available, and trustworthy. In today's world of cloud computing and microservices, reliability now means more than just preventing downtime—it also involves defending against security threats and keeping data safe. Security problems, like DDoS attacks or identity breaches, can harm your system’s reliability as much as technical errors or outages. When either happens, users lose trust and your service’s reputation suffers.</p> <p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; margin: 20px 0;">This is why <em>SecSRE</em> is important: it’s an approach where security and reliability work together. The goal is to build systems that are strong, observable, and protected—so they can keep running well and keep out attackers at the same time.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9400"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Why It Matters</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; margin: 20px 0;">In the past, security checks happened at the very end of the delivery process. That was fine when systems were simple. But today’s cloud-based, fast-moving systems are too complex for that approach.</p> <p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; margin: 20px 0;">Now, security problems happen just as quickly as reliability problems. Both need:</p> <p style="text-align: center; margin: 20px 0;"><img alt="Diagram showing fast detection, quick response, and teamwork" height="284" src="https://imgproxy.citrusreader.com/6FqLiOtrkTMm2nQmv8GzK5Q43iE1KiBkk8xLZb310tk/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzLzIwMjUtMDgvcGljMS5wbmc" style="display: block; margin: 0 auto;" width="424" referrerpolicy="no-referrer"></p> <p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; margin: 20px 0;">The solution is to build security into every step of the process, not just at the end. This way, issues are spotted earlier, handled faster, and the system stays safer and more reliable.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9396"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">What SecSRE Brings</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size:14pt; line-height:1.5; margin:20px 0;">SecSRE extends the proven SRE toolbox—SLIs and SLOs, automation, observability, chaos testing, and blameless postmortems—to security. This involves:</p> <ul style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size:14pt; line-height:1.5; margin-left:20px; margin-bottom:20px;"> <li>Designing <strong>secure-by-default architectures</strong> that fail safely.</li> <li>Integrating <strong>continuous security observability</strong> into monitoring stacks.</li> <li>Automating <strong>threat detection and response</strong>, similar to performance alerts.</li> <li>Stress-testing <strong>defenses with controlled</strong> chaos experiments.</li> </ul> <p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size:14pt; line-height:1.5; margin:20px 0;">The result is a system that remains reliable under normal conditions and resilient against attacks, emerging vulnerabilities, and operational surprises.</p> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9397"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Core Principles of SecSRE</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; margin: 20px 0;">SecSRE builds on the proven practices of Site Reliability Engineering (SRE), adapting them to strengthen security while preserving reliability.</p> <table class="Table" style="border-collapse: collapse; border: 1px solid black; width: 623px;"> <thead> <tr> <th style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; text-align: left;">SRE Principle</th> <th style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; text-align: left;">SecSRE Adaptation</th> </tr> </thead> <tbody> <tr> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">SLIs &amp; SLOs</td> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Add security-focused metrics like MTTD, MTTR, and patch cadence to track performance.</td> </tr> <tr> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Error Budgets</td> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Use breach budgets to define acceptable security risk exposure.</td> </tr> <tr> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Automation</td> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Embed security checks into CI/CD, configuration management, and Infrastructure-as-Code.</td> </tr> <tr> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Chaos Engineering</td> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Run controlled security failure simulations to test resilience.</td> </tr> <tr> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Blameless Postmortems</td> <td style="border: 1px solid black; padding: 8px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;">Analyze incidents without blame to improve security processes.</td> </tr> </tbody> </table> <h2 style="margin-top: 11px; margin-bottom: 5px; color: #0f4761; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; font-weight: normal;">Metrics-Driven Security with Automation &amp; Observability</h2> <p style="margin: 19px 0; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5;">You can’t improve what you don’t measure — and you can’t measure effectively without automation and observability. Just as SRE teams use SLIs and SLOs to quantify availability, SecSRE applies the same discipline to security — ensuring performance is visible, measurable, and actionable.</p> <p style="margin: 19px 0 19px 24px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; font-style: italic;">“You can’t manage what you can’t measure.” — Common principle reinforced in SecurityScorecard guidance</p> <h3 style="margin-top: 11px; margin-bottom: 5px; color: #0f4761; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; font-weight: normal;">Security SLIs</h3> <p style="margin-bottom: 11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;">Service Level Indicators measure how effectively security objectives are being met:</p> <ul style="margin-bottom: 11px; padding-left: 24px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;"> <li style="margin-bottom: 11px;"><b>Mean Time to Detect (MTTD)</b> – How quickly a security incident is identified.</li> <li style="margin-bottom: 11px;"><b>Mean Time to Respond (MTTR)</b> – How quickly a detected incident is mitigated or resolved.</li> <li style="margin-bottom: 11px;"><b>Security Incident Frequency</b> – Number of P0/P1 security incidents over a defined time period.</li> <li style="margin-bottom: 11px;"><b>Patch Cadence</b> – The speed at which security patches are applied, a proven predictor of security outcomes.</li> <li style="margin-bottom: 11px;"><b>Control Health</b> – Uptime and availability of critical security controls (e.g., WAF, EDR, SIEM).</li> </ul> <p style="margin-left: 24px; margin-bottom: 11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black; font-style: italic;">“Measurement without analysis and action wastes time and money and contributes to uncertainty and risk rather than reducing them.” — Lance Hayden, <i>IT Security Metrics</i></p> <h2 style="margin-top: 11px; margin-bottom: 5px; color: rgb(15, 71, 97); font-family: Muli, Klavika, Arial, sans-serif; font-size: 14pt; font-weight: normal;">Security SLOs</h2> <p style="margin-bottom: 11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;">Service Level Objectives turn those indicators into measurable targets:</p> <table style="border-collapse: collapse; width: 465px; border: 1px solid black; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt;"> <thead> <tr> <th style="border: 1px solid black; padding: 8px; text-align: left;">Security SLI</th> <th style="border: 1px solid black; padding: 8px; text-align: left;">Sample SLO</th> </tr> </thead> <tbody> <tr> <td style="border: 1px solid black; padding: 8px;">Patch latency for critical vulns</td> <td style="border: 1px solid black; padding: 8px;">99% patched within 7 days</td> </tr> <tr> <td style="border: 1px solid black; padding: 8px;">MTTD (Mean Time to Detect)</td> <td style="border: 1px solid black; padding: 8px;">Detect P0 (critical) attacks within 5 minutes</td> </tr> <tr> <td style="border: 1px solid black; padding: 8px;">MTTR (Mean Time to Respond)</td> <td style="border: 1px solid black; padding: 8px;">Mitigate incidents within 30 minutes</td> </tr> <tr> <td style="border: 1px solid black; padding: 8px;">Control Health</td> <td style="border: 1px solid black; padding: 8px;">99.9% uptime for all critical security controls</td> </tr> </tbody> </table> <h2 style="margin-top: 19px; margin-bottom: 19px; color: rgb(15, 71, 97); font-family: Muli, Klavika, Arial, sans-serif; font-size: 14pt; font-weight: normal;">Breach Budgets for Security</h2> <p style="margin: 19px 0; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;">In reliability engineering, an <i>error budget</i> defines the maximum allowable downtime before corrective action is taken. <b>Security Site Reliability Engineering (SecSRE)</b> adapts this principle to create a <i>breach budget</i>—a measurable threshold for acceptable security risk before remediation work must take priority.</p> <p style="margin: 19px 0 19px 24px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; font-style: italic; color: black;">“The inverse of your SLO is your error budget—how much unreliability you are willing to tolerate.” — Google SRE Workbook [1]</p> <p style="margin: 19px 0 19px 24px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; font-style: italic; color: black;">“The global average cost of a data breach skyrocketed to $4.88 million in 2024—a 10% increase from the year before, the biggest annual rise since the pandemic.” — IBM Cost of a Data Breach Report 2024 [2]</p> <p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;">These figures underscore why breach budgets are essential—they ensure security risks are quantified, tracked, and addressed before they can escalate into costly incidents.</p> <h2 style="margin-top: 11px; margin-bottom: 5px; color: #0f4761; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; font-weight: normal;">Automation-First Approach</h2> <p style="margin-bottom: 11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;">Manual security checks don’t scale in fast-moving environments. SecSRE applies automation to embed security seamlessly into every stage of software delivery, ensuring continuous protection without slowing down innovation.</p> <p style="margin-left:24px; margin-bottom:11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black; font-style: italic;">The DevSecOps Handbook states [3]: <b>“Security must be built into every stage of the software delivery lifecycle — not bolted on at the end.”</b> This philosophy underpins the SecSRE automation strategy, ensuring security is proactive and integrated, rather than reactive and siloed.</p> <p style="margin-bottom:11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;"><b>Key Practices:</b></p> <ul style="margin-bottom:11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;"> <li><b>Security Gates in CI/CD</b> – Automatically fail builds if critical vulnerabilities are detected.</li> <li><b>Continuous Compliance Scans</b> – Identify configuration drift or policy violations without human intervention.</li> <li><b>Observability-Driven Metrics</b> – Collect detection coverage, alert latency, and incident trends to guide breach budget and response improvements.</li> <li><b>Automated Access Governance</b> – Enforce <i>just-in-time</i> (JIT) approvals, auto-expire unused credentials, and flag excessive or privileged permissions in infrastructure and cloud IAM.</li> <li><b>Privilege Escalation Detection</b> – Alert on unusual admin rights or role changes.</li> <li><b>Automated Alerting</b> – Use tuned alerting mechanisms to minimize false positives and reduce alert fatigue.</li> </ul> <p style="margin-bottom:11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black; text-align: center;"><img alt="diagram_font_increased" height="572" src="https://imgproxy.citrusreader.com/6TWGeWWtCWlh6YmAeWeuxAcZ11pO3l_JodtF42U8XJk/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzLzIwMjUtMDgvc3JlZGVwbG95bWVudC5wbmc" style="display: block; margin: 0 auto;" width="898" referrerpolicy="no-referrer"></p> <p style="margin-bottom:11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 12pt; line-height: 1.3; color: #156082; font-weight: bold; text-align: center;">Architecture flow along with the tools used</p> <h2 style="margin-top:11px; margin-bottom:5px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.15; color:#0f4761; font-weight: normal;">Chaos Engineering for Security (with Fuzzing)</h2> <p style="margin:5px 0; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;">If chaos engineering helps us uncover reliability weaknesses, it can also reveal hidden security gaps. SecSRE promotes deliberate, controlled security “chaos experiments,” such as:</p> <p style="margin:5px 0 5px 24px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; font-style: italic; color: black;">“GameDay… a project to increase reliability by purposefully creating major failures on a regular basis.” — Jesse Robbins, on chaos engineering in AWS</p> <ul style="margin-bottom:11px; padding-left: 24px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black;"> <li><b>Simulating credential leaks</b> – to test detection and response.</li> <li><b>Injecting malicious traffic</b> – to validate intrusion prevention rules.</li> <li><b>Temporarily disabling a security control</b> – to measure fallback mechanisms.</li> <li><b>Running fuzzing campaigns</b> – against APIs, services, and input-handling components to discover unexpected vulnerabilities or crashes before attackers can exploit them.</li> </ul> <p style="margin:5px 0; font-family:'Muli','Klavika',Arial,sans-serif; font-size:14pt; line-height:1.5; color:black; font-style:italic;">“You’d define a steady state and your control groups. You’d form your hypothesis… run an experiment… verify the results.” — Crystal Hirschorn</p> <p style="margin:5px 0; font-family:'Muli','Klavika',Arial,sans-serif; font-size:14pt; line-height:1.5; color:black; font-style:italic;">&nbsp;</p> <p style="margin-bottom:11px; font-family: 'Muli', 'Klavika', Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black; text-align: center;"><img alt="diagram_font_increased" height="572" src="https://imgproxy.citrusreader.com/gEsGmPh5Q8NkTt1oNIbr7Q_1SA7A8Ao17nsU9Vf5RIg/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzLzIwMjUtMDgvY2ljZC5wbmc" style="display: block; margin: 0 auto;" width="898" referrerpolicy="no-referrer"></p> <p style="margin:5px 0; font-family:'Muli','Klavika',Arial,sans-serif; font-size:14pt; line-height:1.5; color:black; font-style:italic;">&nbsp;</p> <p style="margin:5px 0; font-family:'Muli','Klavika',Arial,sans-serif; font-size:14pt; line-height:1.5; color:black;">&nbsp;</p> <ul style="margin-bottom:11px; padding-left:24px; font-family:'Muli','Klavika',Arial,sans-serif; font-size:14pt; line-height:1.5; color:black;"> <li><b>Code Commit</b> – Developer pushes changes to the repository.</li> <li><b>Automated Build</b> – Pipeline triggers build and dependency checks.</li> <li><b>Static/Dynamic Analysis</b> – Security scanners run for known vulnerabilities (e.g., <b>CVEs</b>, <b>Secrets</b>).</li> <li><b>Deep Fuzzing Stage</b> – Tools like <b>AFL++, OSS-Fuzz, or Jazzer</b> run targeted fuzz tests on binaries or APIs, generating high-volume, randomized inputs to expose edge-case failures.</li> <li><b>Fail on Detection</b> – If critical issues are discovered, the build fails automatically.</li> <li><b>Reporting &amp; Metrics</b> – Results feed into security observability dashboards for tracking detection coverage, time-to-detect, and remediation rate.</li> </ul> <h2 style="margin-top:11px; margin-bottom:5px; font-family:Klavika, Arial, sans-serif; font-size:14pt; color:#0f4761; font-weight:normal;">Blameless Security Postmortems</h2> <p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;">In security-centric Site Reliability Engineering (SecSRE), the goal of a postmortem is not to assign fault but to turn every incident into a structured learning opportunity that hardens both systems and teams.</p> <ul style="margin-bottom:11px; padding-left:24px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;"> <li><b>Structured, Security-Focused Reviews</b> – Every postmortem follows a consistent, security-oriented template that captures timelines, attack vectors, exploited vulnerabilities, control failures, and detection gaps. Ensures repeatable, bias-free analysis and benchmarking against prior incidents.</li> <li><b>Systemic Root Cause Analysis</b> – Focus on system-level weaknesses like policy gaps, configuration drift, insufficient monitoring coverage, or delayed patching, rather than individual mistakes.</li> <li><b>Cross-Functional Collaboration</b> – Security, reliability, and development teams jointly participate, ensuring findings reflect operational realities and remediation plans are feasible and risk-prioritized.</li> <li><b>Actionable, Measurable Outcomes</b> – Each postmortem produces concrete security improvements (e.g., updated detection rules, automated CI/CD guardrails, policy changes) tracked to completion with clear success criteria.</li> <li><b>Organizational Security Memory</b> – Lessons learned are documented in a centralized, accessible repository and periodically reviewed to strengthen resilience and accelerate onboarding for future threats.</li> </ul> <h2 style="margin-top:11px; margin-bottom:5px; font-family:Klavika, Arial, sans-serif; font-size:14pt; color:#0f4761; font-weight:normal;">Challenges and Ownership in SecSRE</h2> <p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;">Adopting Security Site Reliability Engineering (SecSRE) blends two traditionally separate worlds—security and reliability. The payoff is huge, but so are the challenges.</p> <p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;"><b>1. Defining Responsibility</b><br> Security and reliability often live in different departments, with different metrics and mindsets. Without clear ownership, important work risks falling through the cracks. A shared model that assigns <i>specific accountability</i> for each area—like the “Who Owns What?” diagram—keeps everyone aligned.</p> <p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;"><b>2. Bridging Skill Gaps</b><br> SREs excel at uptime, automation, and performance tuning, but may lack deep knowledge of threat modeling or secure coding. Security teams know risks and vulnerabilities inside-out but may be unfamiliar with production constraints. Cross-training, joint drills, and shared tools help both sides learn from each other.</p> <p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;"><b>3. Cultural Alignment</b><br> SRE culture prizes speed and reducing toil, while security sometimes prioritizes thoroughness over velocity. In SecSRE, both need to meet in the middle—integrating strong controls without slowing innovation.</p> <p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;"><b>4. Measuring What Matters</b><br> Meaningful metrics are tricky when balancing both reliability and security. Without agreed-upon measures, it’s impossible to track whether the system is getting safer <i>and</i> more reliable. This is where joint SLIs/SLOs and shared dashboards become essential.</p> <table style="border-collapse: collapse; border: none; width: 100%;"> <tbody> <tr> <td style="width: 50%; padding: 0 7px; border: none;" valign="top"> <p style="margin-bottom: 11px;"><img alt height="1024" src="https://imgproxy.citrusreader.com/LN-XzSBwNTNDtOTbAtkGPnlnG-kfX9wrMQvX2OZkrZw/raw:1/aHR0cHM6Ly93d3cudXNlbml4Lm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzLzIwMjUtMDgvd2hvb3duc3doYXQucG5n" width="1536" referrerpolicy="no-referrer"></p> </td> <td style="padding: 0 7px; border: none;" valign="top"> <p style="font-family: Muli, Arial, sans-serif; font-size: 14pt; line-height: 1.5; color: black; margin-bottom: 11px;">This ownership map ensures that every security and reliability responsibility – from patch management to incident response – has a clear point of accountability. It transforms SecSRE from a shared aspiration into a structured, day-to-day reality.</p> </td> </tr> </tbody> </table> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9398"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Real-World Inspiration</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="font-size:14pt; font-family:'Muli', 'Klavika', Arial, sans-serif; color:black; margin-bottom:11px;">Several organizations already embody aspects of SecSRE:</p> <ul style="font-size:14pt; font-family:'Muli', 'Klavika', Arial, sans-serif; color:black; margin-bottom:11px; padding-left:20px;"> <li style="margin-bottom:11px;"><b>Google Cloud</b> has shown how SRE automation techniques improve Security Operations Center workflows [2].</li> <li style="margin-bottom:11px;"><b>Datadog</b> merged SRE and Security teams to improve both incident response times and accountability [3].</li> <li style="margin-bottom:11px;"><b>Mindflow.io</b> advocates treating security as part of system reliability rather than as a separate function [4].</li> </ul> </div></div></div> </div> </div> </div><div class="field-item even"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9399"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">From SRE to SecSRE</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="font-size:14pt; font-family:'Muli', 'Klavika', Arial, sans-serif; line-height:1.5; margin:20px 0;">SRE teams already know how to build reliable, fault-tolerant systems. Extending that mindset to security means:</p> <ul style="font-size:14pt; font-family:'Muli', 'Klavika', Arial, sans-serif; line-height:1.5; margin-left:20px; margin-bottom:20px;"> <li>Treating security failures like availability failures.</li> <li>Automating security processes as rigorously as deployments.</li> <li>Defining security SLIs and tracking breach budgets.</li> <li>Designing systems that assume security controls can—and will—fail.</li> </ul> <p style="font-size:14pt; font-family:'Muli', 'Klavika', Arial, sans-serif; line-height:1.5; margin:20px 0;">SecSRE is not a job title. It is a shared responsibility model that makes security a first-class citizen in engineering culture.</p> </div></div></div> </div> </div> </div><div class="field-item odd"><div class="paragraphs-item paragraphs-item-single-column-text paragraphs-item-single-column-text paragraphs-item-full paragraphs-item-9406"> <div class="content"> <div class="field field-name-field-single-column-sub field-type-text field-label-hidden"><div class="field-items field-items"><div class="field-item odd">Acknowledgments</div></div></div><div class="field field-name-field-single-column-text field-type-text-long field-label-hidden"><div class="field-items field-items"><div class="field-item odd"><p style="margin-bottom:11px; font-family:Muli, Arial, sans-serif; font-size:14pt; line-height:1.5; color:black;">We are grateful to Roy Antonyraj for their guidance and constructive feedback.</p> </div></div></div> </div> </div> </div></div></div></div> <fieldset class="group-appendix field-group-fieldset form-wrapper"><legend><span class="fieldset-legend">Appendix</span></legend><div class="fieldset-wrapper"><div class="field field-name-field-lvl2-appendix-refs field-type-text field-label-above"><div class="field-label">References:&nbsp;</div><div class="field-items field-items"><div class="field-item odd"><a class="anchor" name="reference-1"></a><p>[1] The Site Reliability Workbook: Practical Ways to Implement SRE.O’Reilly Media, 2018. ISBN: 978-1492029502</p> </div><div class="field-item even"><a class="anchor" name="reference-2"></a><p>[2] Cost of a data breach 2024: Financial industry - <a href="https://www.ibm.com/think/insights/cost-of-a-data-breach-2024-financial-industry">https://www.ibm.com/think/insights/cost-of-a-data-breach-2024-financial-...</a></p> </div><div class="field-item odd"><a class="anchor" name="reference-3"></a><p>[3] Kim, G., Willis, J., Humble, J., &amp; Debois, P. (2016). The DevSecOps Handbook. IT Revolution Press.</p> </div><div class="field-item even"><a class="anchor" name="reference-4"></a><p>[4] Google Cloud Case Studies. “Integrating SRE Automation with SOC Operations.”</p> </div><div class="field-item odd"><a class="anchor" name="reference-5"></a><p>[5] Datadog Engineering Blog. “Bridging the Gap Between SRE and Security.”</p> </div><div class="field-item even"><a class="anchor" name="reference-6"></a><p>[6] Mindflow.io Blog. “Security as Reliability.”</p> </div><div class="field-item odd"><a class="anchor" name="reference-7"></a></div><div class="field-item even"><a class="anchor" name="reference-8"></a></div><div class="field-item odd"><a class="anchor" name="reference-9"></a></div><div class="field-item even"><a class="anchor" name="reference-10"></a></div><div class="field-item odd"><a class="anchor" name="reference-11"></a></div><div class="field-item even"><a class="anchor" name="reference-12"></a></div><div class="field-item odd"><a class="anchor" name="reference-13"></a></div><div class="field-item even"><a class="anchor" name="reference-14"></a></div><div class="field-item odd"><a class="anchor" name="reference-15"></a></div><div class="field-item even"><a class="anchor" name="reference-16"></a></div><div class="field-item odd"><a class="anchor" name="reference-17"></a></div><div class="field-item even"><a class="anchor" name="reference-18"></a></div><div class="field-item odd"><a class="anchor" name="reference-19"></a></div><div class="field-item even"><a class="anchor" name="reference-20"></a></div><div class="field-item odd"><a class="anchor" name="reference-21"></a></div><div class="field-item even"><a class="anchor" name="reference-22"></a></div><div class="field-item odd"><a class="anchor" name="reference-23"></a></div><div class="field-item even"><a class="anchor" name="reference-24"></a></div><div class="field-item odd"><a class="anchor" name="reference-25"></a></div><div class="field-item even"><a class="anchor" name="reference-26"></a></div><div class="field-item odd"><a class="anchor" name="reference-27"></a></div><div class="field-item even"><a class="anchor" name="reference-28"></a></div><div class="field-item odd"><a class="anchor" name="reference-29"></a></div><div class="field-item even"><a class="anchor" name="reference-30"></a></div><div class="field-item odd"><a class="anchor" name="reference-31"></a></div><div class="field-item even"><a class="anchor" name="reference-32"></a></div><div class="field-item odd"><a class="anchor" name="reference-33"></a></div><div class="field-item even"><a class="anchor" name="reference-34"></a></div><div class="field-item odd"><a class="anchor" name="reference-35"></a></div><div class="field-item even"><a class="anchor" name="reference-36"></a></div><div class="field-item odd"><a class="anchor" name="reference-37"></a></div><div class="field-item even"><a class="anchor" name="reference-38"></a></div><div class="field-item odd"><a class="anchor" name="reference-39"></a></div><div class="field-item even"><a class="anchor" name="reference-40"></a></div><div class="field-item odd"><a class="anchor" name="reference-41"></a></div><div class="field-item even"><a class="anchor" name="reference-42"></a></div><div class="field-item odd"><a class="anchor" name="reference-43"></a></div><div class="field-item even"><a class="anchor" name="reference-44"></a></div><div class="field-item odd"><a class="anchor" name="reference-45"></a></div><div class="field-item even"><a class="anchor" name="reference-46"></a></div><div class="field-item odd"><a class="anchor" name="reference-47"></a></div><div class="field-item even"><a class="anchor" name="reference-48"></a></div><div class="field-item odd"><a class="anchor" name="reference-49"></a></div><div class="field-item even"><a class="anchor" name="reference-50"></a></div></div></div></div></fieldset>

2025/8/24
阅读更多

推荐订阅