This NINJIO Insights Report dives into the key emotional susceptibilities that make social engineering work and offers concrete steps that your security team can take to equip your workforce to resist cyberattacks.
Download the Guide
There is an odd thing happening to cybersecurity work. The threats are getting faster, the infrastructure is getting more complicated, and the number of things we are supposed to secure continues to grow. Yet, at the same time, a growing proportion of the actual work is becoming easier to perform. That does not necessarily mean security professionals will have less work, and anyone hoping that artificial intelligence would usher in the four-hour SOC shift is probably going to be disappointed.
What it does mean is that the contents of an ordinary working day are beginning to change. We can already see the beginnings of a security profession in which humans spend less time collecting information and more time deciding what should happen next. Some of that change is coming from generative AI, while some is the continuation of automation trends that have been developing for years. The interesting question is how far that transition goes.
The Claude Code Security Summit takes place online on 25 September and focuses on the security implications of AI coding agents as they move beyond code completion. Across six hours of practitioner-led sessions, the event will examine how teams can define security requirements, test AI-generated applications, manage coding-agent and MCP trust boundaries, and establish appropriate human approval points. The programme includes Jim Manico, Vandana Verma, Katie Paxton-Fear and Michael Shost, bringing together perspectives from secure development, application security, ethical hacking and enterprise governance.
The sessions are aimed at developers, AppSec and product security teams, DevSecOps practitioners, security engineers and technical leaders working with Claude Code or other coding agents. Rather than concentrating on prompting techniques, the summit looks at the controls surrounding AI-assisted development, including SECURITY.md and CLAUDE.md, adversarial testing, MCP trust boundaries, least-privilege access and production approval. There will also be live demonstrations covering the process from generating code through attacking, remediating and validating it. _secpro readers can register using code SECPRO30.
Register for the CCSS
Go back ten years and the working environment looks familiar enough. There were SIEM platforms, endpoint security products, vulnerability scanners, IDS/IPS systems and increasingly sophisticated threat intelligence feeds. Security teams were certainly not working with stone tools, but humans sat much closer to the machinery. A considerable amount of the working day involved extracting information from those systems, comparing it and deciding what it meant.
The 2016 SANS Security Analytics Survey provides a useful snapshot. Endpoint monitoring software was the most common way organisations were alerted to security events, followed by automated SIEM alerts. Analysts were also manually searching SIEM platforms, reviewing historical logs and correlating information from different security products. In other words, much of what we now describe as security analytics involved a person sitting in front of security tooling and figuring out what several different pieces of information meant.
The threats themselves sound remarkably familiar. Verizon’s 2016 DBIR found that 63% of confirmed breaches involving hacking leveraged weak, default or stolen passwords, while phishing, malware, web application attacks and compromised credentials occupied plenty of defenders’ time. There is an important difference
