Karamihan sa mga kuwentong pangseguridad sa newsletter na ito ay tungkol sa mga bagay na direktang nangyayari sa iyo: isang phishing na text, isang tumagas na password, isang pekeng shopping site. Naiiba ang isang ito. Ang mga insidenteng nasa ibaba ay nangyari sa mga developer — ang mga taong sumusulat ng mga app at serbisyong ginagamit mo araw-araw. Ngunit simple ang dahilan kung bakit kabilang ito rito: kung lalason ang isang tao sa mga tool na ginagamit sa pagbuo ng software, hindi mananatili ang lason sa gumawa. Kasama ito sa ipinapadalang produkto.

May dalawang bagay na nangyari kamakailan na naglalarawan nito. Hindi naging laman ng mga pangunahing balita gaya ng isang malaking data breach, dahil hindi direktang paglabag sa iyo ang alinman sa mga ito. Pareho silang pag-atake sa pipeline na gumagawa ng software na kalaunan ay ini-install, binubuksan, o nilalagyan mo ng login.

Mga pekeng extension na nagkunwaring mga pinagkakatiwalaang brand

Ang Open VSX ay isang pampublikong marketplace para sa mga extension ng code editor — maliliit na add-on na ini-install ng mga developer para magkaroon ng autocomplete, linting, at mga integration para sa mga tool na ginagamit nila araw-araw (kumukuha rito ang Visual Studio Code at ilan sa mga open-source na kahawig nito). Sa pagitan ng Hulyo 26 at Agosto 1, 2026, nakahanap ang mga security researcher sa Manifold Security ng 77 pekeng extension sa registry. Bawat isa ay kumopya sa pangalan at namespace ng isang tunay at pinagkakatiwalaang extension, ngunit inilathala mula sa account na hindi nagmamay-ari ng orihinal — isang klasikong panggagaya na kung minsan ay tinatawag na namespace squatting.

Hindi basta-basta ang mga sinquat na pangalan. Hiniram ng mga ito ang pagkakakilanlan ng AMD, LEGO Education, Hyperledger, Azure, Artsy, mga open-source project ng Salesforce, isang ahensiya ng pederal na pamahalaan ng U.S., at — sa isang uri ng madilim na kabalintunaan — ang mismong extension marketplace. Lahat ng 77 package ay kumontak sa iisang domain na nairehistro 11 araw lamang bago lumitaw ang unang pekeng package, isang padron na nagpapahiwatig ng koordinado at sadyang binuong kampanya sa halip na oportunistikong panggagaya.

Karamihan sa mga pekeng extension ay may katamtamang ginagawa: tahimik nilang ipinapadala sa server ng umaatake ang hostname, na maaaring simpleng pagsusuri lamang kung sino ang nag-install ng pain. Ngunit natuklasan ng mga researcher na humigit-kumulang sangkapat ng 77 — 19 package — ang mas lumalayo pa. Ilang segundo matapos i-activate, kinokolekta nila ang hostname, username ng operating system, mga detalye ng editor, at machine ID. Pagkatapos ay binabasa nila ang anumang project na bukas sa developer: ang git remote (na nagbubunyag ng organisasyon at host ng repository), ang domain ng commit email, ang kasalukuyang branch, at ang pinakabagong commit. Kinukuha rin nila ang mga value ng tuloy-tuloy na integration — ang mga credential at configuration na nagpapahintulot sa mga automated system na mag-build at mag-deploy ng code nang hindi kailangang mag-type ng password ang tao sa bawat pagkakataon.

Wala sa mga datos na iyon ang kapaki-pakinabang para maubos ang laman ng bank account ng isang tao. Kapaki-pakinabang ang mga ito para sa ibang bagay: alamin kung saang kumpanya nagtatrabaho ang isang developer, ano ang hitsura ng panloob nilang imprastraktura, at paano makakakuha ng foothold dito.

Isang bug na 9.8 sa 10 sa makinang nagbuo ng software

Ang ikalawang insidente ay kinasasangkutan ng TeamCity, isang platform para sa continuous integration at continuous delivery (CI/CD) na ginawa ng JetBrains. Kung ang code editor ang lugar kung saan sumusulat ng software ang mga developer, ang CI/CD platform naman ang awtomatikong pabrika kung saan kino-compile, tine-test, at ipinapadala sa production ang code — madalas nang walang taong kailangang mag-click sa "deploy." Sentral na bahagi ng makinaryang iyon ang TeamCity sa maraming kumpanya.

Isang kahinaang sinusubaybayan bilang CVE-2026-63077, na may severity score na 9.8 mula sa posibleng 10, ang isiniwalat sa mga on-premises na bersyon ng TeamCity. Isa itong deserialization flaw — uri ng bug kung saan sapat ang tiwala ng program sa dumarating na data para direktang gawin itong tumatakbong code, nang hindi muna sinusuri kung ano talaga ang data. Sa aktuwal, pinahintulutan nito ang isang umaatake na magpadala ng request sa isang bulnerableng TeamCity server, nang hindi kinakailangang mag-login, at magpatakbo ng anumang command na may kaparehong pribilehiyo ng mismong TeamCity service. Naglabas ang JetBrains ng mga patch (bersyon 2025.11.7 at 2026.1.3, kasama ang isang patch plugin para sa mas lumang 2017.1+ installation), ngunit nagbabala na ang U.S. Cybersecurity and Infrastructure Security Agency (CISA) na aktibong ine-exploit na ngayon ng mga umaatake ang mga sistemang hindi pa na-patch.

Kung sino ang kumokontrol sa build server ng isang kumpanya, siya ang kumokontrol sa ipinapadala ng kumpanyang iyon. Hindi iyon haka-haka — literal na tungkulin iyon ng tool.

Parehong playbook, dalawang magkaibang pinto

Magkaibang insidente ito mula sa magkakaibang researcher, ngunit magkapareho ang anyo. Wala sa mga ito ang umaatake sa tapos nang produkto. Pareho nilang ina-atake ang mas naunang hakbang — ang editor kung saan nagsusulat ng code ang developer, o ang server na ginagawang inilabas na release ang code na iyon. Iyan ang katangiang tumutukoy sa pag-atake sa software supply chain: sa halip na pasukin ang isang target, kinokompromiso mo ang isang upstream na bagay na umaasa rito ang maraming target, at hinahayaan mong ang sarili nilang pinagkakatiwalaang proseso ang magdala ng access mo pasulong para sa iyo.

Mahalagang maging tapat tungkol sa mga hindi pa natin alam. Wala sa dalawang ulat na lumitaw ngayong linggo ang nagsiwalat ng kumpirmadong kaso na direktang nakompromiso ang isang downstream app o user bilang resulta — mukhang reconnaissance at pangangalap ng access ang kampanya sa mga extension, at inilarawan ang pag-exploit sa TeamCity bilang aktibo ngunit walang pinangalanang biktima. Karaniwan iyan; madalas natutuklasan ang mga kompromiso sa supply chain sa entry point bago pa man (o sa halip na) matunton ang kalaunang pakinabang.

Bakit problema mo ito, hindi lang nila

Malamang na hindi ka kailanman mag-i-install ng coding extension o magpapatakbo ng CI/CD server. Ngunit ginagamit mo ang output ng daan-daang gayon: ang banking app mo, ang password manager mo, ang school portal ng anak mo, ang browser na ginagamit mo sa pagbabasa nito. Dumaan ang lahat ng iyon sa editor ng isang developer at sa build pipeline ng isang kumpanya bago makarating sa phone mo. Kung tahimik na nakompromiso ang alinman sa mga link na iyon, maaaring sumabay ang malisyosong pagbabago sa isang karaniwan at regular na software update — iyong ini-install mo dahil sinabihan kang ang pag-update ang ligtas na gawin.

Ito rin ang dahilan kung bakit kung minsan ay kakaiba sa mga hindi teknikal na mambabasa ang payo sa isang breach postmortem: sinasabi ng isang kumpanya na nakompromiso ang mga sistema nito sa pamamagitan ng build server, ninakaw na credential ng developer, o malisyosong dependency, at maaaring magmukhang abstrakto iyon kumpara sa "may nanghula ng password ko." Hindi ito abstrakto. Pareho ang kinalabasan — nakompromiso ang datos mo o ang integridad ng app mo — ngunit nakarating dito sa pamamagitan ng pintong hindi mo alam na umiiral.

Ano talaga ang nakatutulong

Hindi mo kayang i-audit ang CI/CD pipeline ng bangko mo, at hindi mo naman dapat kailangang gawin iyon. Ngunit may ilang gawi na tunay na nakakabawas sa exposure mo sa ganitong uri ng panganib:

Panatilihing naka-on ang mga awtomatikong update, ngunit huwag ituring na awtomatikong mapagkakatiwalaan ang mga update. Sa pamamagitan ng mga patch nakararating sa software na pinapatakbo mo ang mga pag-aayos gaya ng nasa TeamCity sa itaas — ang pananatiling napapanahon ay nagsasara ng mga puwang na aktibong sinusuri ng mga umaatake. Kasabay nito, kasinghusay lamang ng pipeline na gumawa rito ang isang update, at iyon mismo ang tina-target dito; walang perpektong indibidwal na depensa laban sa isang tunay na nalason na upstream release, kaya sa panimula ay problema ito ng pananagutan ng vendor, hindi problema mo.

Kung nagtatrabaho ka kasama ng mga developer o namamahala sa kanila, may dalawang kongkreto at masusuring bagay: tiyaking ang anumang code-editor extension ay naka-install mula sa aktuwal na verified publisher account, hindi sa pangalan lamang na tugma (ipinapakita ng Open VSX at mga kahalintulad na marketplace ang pagkakakilanlan ng publisher — suriin ito, huwag umasa sa icon at pamagat lamang); at kung nagpapatakbo ang organisasyon ninyo ng TeamCity on-premises, kumpirmahing nasa 2025.11.7, 2026.1.3, o nailapat na ang patch plugin, ngayon, hindi sa susunod na maintenance window — ibig sabihin ng babala ng CISA ay aktibong ine-exploit ito, hindi lamang teorya.

Para sa iba pa, ang kapaki-pakinabang na pagbabago ay simpleng kamalayan: kapag nagbasa ka tungkol sa breach ng isang kumpanya na nag-ugat sa "nakompromisong developer tool" o "build system," hindi iyon isang maliit na teknikal na talababa. Pareho itong kategorya ng insidente gaya ng mga paglabag sa password at phishing scam na mas madalas saklawin ng newsletter na ito — nagsimula lamang ito sa isang patong na mas upstream, bago pa man makarating sa iyo ang produkto.