Recently active topics

A few weeks ago I wrote about what building Skyforge taught me about network emulation and digital twins. If you haven’t read it, you can find it here: The response was much larger than I expected, but one conversation afterwards stuck with me.An colleague mentioned they were starting to hear a different question from customers. It wasn’t really about digital twins anymore. It was about AI.If tools like Claude can generate software this quickly, doesn’t that fundamentally change the build-versus-buy equation?It’s a fair question, and honestly, it’s one I’ve been asking myself as well.After all, I spent the last six months building Skyforge with Claude sitting beside me. I don’t mean that as a marketing statement about AI. I mean it literally. Large parts of the platform, from Go services and Kubernetes manifests to GitOps workflows, deployment automation, documentation, and countless little pieces of glue code started life as conversations instead of blank files.There is absolutely no

Some cyberattacks need a zero-day to make headlines. This one didn't. For years, Russian intelligence has simply walked through open doors: default SNMP community strings left unchanged, Cisco's Smart Install left switched on, routers nobody got around to patching. That activity was significant enough to bring eighteen agencies together on a single warning. NSA, CISA, FBI, and DC3 in the United States joined fourteen international partners, including the UK's NCSC, Australia's ACSC, and Canada's Cyber Centre, to co-sign a joint advisory: AA26-194A, "Improve Router Hygiene to Protect Against Russian State-Sponsored Targeting." When that many agencies put their names on one document, it's worth reading closely. Russian FSB Center 16 actors (tracked in the industry as Berserk Bear, Energetic Bear, Dragonfly, and Static Tundra, among other names) have been opportunistically compromising routers and switches worldwide for over a decade, and they're still finding plenty of them, not through

Environment:Forward Networks (self-hosted) ServiceNow CMDB integration via NQE query Target class: cmdb_ci_ip_firewallIssue:When mapping System Criticality (a ServiceNow choice field) from an NQE query to ServiceNow via Forward's native CMDB integration, the field consistently reports "data type mismatched" regardless of the value format used.Attempted formats — all result in data type mismatched:"System Criticality": "2" "System Criticality": 2 "System Criticality": "2 - High" "System Criticality": ["2"] "System Criticality": [2] "System Criticality": ["2 - High"] Top-level named list: systemCriticality = ["2"] referenced in selectQuestion:Is ServiceNow choice field type mapping supported in Forward's NQE→CMDB integration? If so, what is the correct NQE syntax or integration configuration to map to a choice field without a type mismatch?Current workaround being considered:ServiceNow business rule that sets system_criticality = "2" on insert/update when discovery_source == "Forward Net

Does anyone know if there is a log or export for the push to service now? We are having an issue with service now processing the model_id (ref). It looks like forward is mapping “model” to both snow’s model_number and model_id. However, it looks like it isn’t being processed on the cmdb side. I just want to see if there is a way to show evidence of the payload forward is sending.  Thank you

On June 18, 2026, CISA issued an urgent advisory warning that malicious cyber actors — believed to be a Russian-speaking criminal group — have compromised nearly 74,000 Fortinet firewall and VPN devices across 194 countries in a campaign now dubbed FortiBleed. The list of affected organizations spans global enterprises and, most alarmingly, a Turkish NATO defense contractor from which classified documents were successfully exfiltrated. As of this writing, independent telemetry puts the number of compromised devices at over 86,000.CISA’s recommended actions are straightforward: terminate all SSL VPN and administrative sessions, reset credentials, enable phishing-resistant MFA, migrate password storage to PBKDF2 hashing, and restrict management interfaces from the public internet.Good advice. But reactive. The more important question is: could your team have known these conditions existed before attackers found them?The answer, for organizations running Forward Networks, is yes.The campa