Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Wireless networks are often assumed to be secure once WPA2 is enabled. In practice, that assumption is only partly true. While WPA2 remains widely used and is not inherently broken, the real security of a wireless network depends heavily on how it is configured, how client devices behave, and how strong the Pre-Shared Key (PSK) actually is. As a result, the protocol label alone can sometimes create a misleading sense of security.

A few months ago, I attended a GC AI Summit hosted by Harvard Law School. As expected, there was plenty of discussion about AI tools, governance frameworks, emerging regulations, and the future of the legal profession. One topic of discussion stood out above the others: Most organizations only need to think about how they deploy AI, whereas we have to think about how we deploy AI and how we develop AI.

Veracode Research’s latest secure-coding test finds GPT-5.6 Sol with a 15-point Python gain beneath modest aggregate movement, evidence that cyber capability and secure-code generation do not move in lockstep. OpenAI calls GPT-5.6 Sol its “strongest cybersecurity model yet.” Veracode’s extension test finds it scoring only two percentage points higher overall on secure-code generation than GPT-5.5, but it scores 15 points higher in Python.

Network edge vulnerabilities are accelerating. Cato’s cloud-native architecture reduces customers’ attack surface and shortens exposure to emerging vulnerabilities. The Cato CVE Exposure Calculator shows what that difference could mean for your organization. Another Known Exploited Vulnerability (KEV). Another emergency CAB. Another weekend spent upgrading firmware. You have to respond. The question is how much each response costs the business.

UpGuard connects to ServiceNow across the whole platform. Vendor risk findings, breach alerts, and user risk signals all land in the same ticket queue your team already works from, not a separate, siloed risk dashboard. With this integration, you can: Risk Automations makes this possible. You define the events that matter: a monitored vendor picks up a new risk, a risk score drops below a threshold you set, a credential breach turns up on a watched domain, or a questionnaire response comes in.

Periodic vulnerability scans are no longer a reliable security program for hybrid environments. NIST's guidance treats scanning as a recurring, risk-based control that should account for changing vulnerabilities, historical results, authenticated coverage, and correlations between findings over time (NIST vulnerability-scanning guidance). Industry practice is moving in the same direction.

Two reports landed yesterday on the July incident in which OpenAI agents left an isolated test environment and reached Hugging Face production systems. OpenAI published a thirty-seven page technical post-mortem. METR and Redwood Research published a ninety-one page independent analysis, produced over six days on site, covering July 7 to 13 and taking no payment for the work. ‍ The coordination numbers are what drew attention.

Early on in the AI adoption boom, I gained a reputation for just throwing everything at it to see what would stick. That wasn’t the most effective strategy, and my token usage was crazy high. There are a ton of talks and posts on all the cool ways you can use AI for detection engineering, but I didn’t see any that showed you where to begin.

At 1Password, we started expanding our use of AI with a familiar IT playbook. We identified the problems we wanted to solve and the tools that could help us achieve those goals. The plan was straightforward: enable teams, move quickly, learn what worked, and build the visibility needed to manage the cost.