Logo
Cybersecurity

Security Teams Need to Understand How Software Actually Gets Shipped

Finding vulnerabilities still matters. Preventing weak code, dependencies and configurations from reaching production requires a different set of skills.

ITSEC AsiaITSEC Asia
|
Okt 05, 2026
Security Teams Need to Understand How Software Actually Gets Shipped

A security professional reviews an application and finds a vulnerability. The development team fixes it. Everyone moves on.

Then the same type of problem appears in the next release.

That’s usually a clue that the weakness lives somewhere deeper than one piece of code. Perhaps the build process accepts an unsafe dependency. A security check happens too late. A container configuration is copied from an old template. Developers receive feedback after the release is practically finished.

NIST’s National Cybersecurity Center of Excellence is putting more attention on exactly this part of software security. Its updated DevSecOps resources, published on 24 September, include CI/CD pipeline automation, containerized application deployment and functional scenarios showing security activities throughout the software development lifecycle. NIST

The workforce implication is straightforward. Application security professionals increasingly need to understand how software moves from a developer’s machine into production.

Security Work Is Moving Into the Pipeline

Traditional security testing can happen near the end of development. DevSecOps pushes security activities into the processes developers already use to build, test and deploy software.

That requires people who can work across disciplines.

Useful DevSecOps capability includes understanding:

  • How source code moves through a CI/CD pipeline
  • Where automated security testing should occur
  • How dependencies and software components are tracked
  • How containers and deployment configurations are built
  • Which findings should block a release and which require review
  • How credentials and secrets are handled during builds
  • How security feedback reaches developers quickly enough to be useful

NIST’s DevSecOps project maps practices from its Secure Software Development Framework into a reference model intended to show how security tasks can operate within modern development pipelines. NCCoE

NICE has also added DevSecOps as a formal competency area in version 2.2.0 of its cybersecurity workforce framework. NIST

That puts software delivery knowledge squarely inside cybersecurity skills development.

Automation Still Needs Judgment

A pipeline can run dozens of checks before software reaches production. That doesn’t mean every alert deserves to stop a release.

Someone still has to understand context.

A vulnerable component might be unreachable in the application. Another finding may expose an internet-facing function handling sensitive information. A failed configuration test could indicate a minor deviation or a serious exposure.

The security professional needs enough development knowledge to discuss the finding with engineers and enough risk judgment to decide what deserves immediate attention.

Otherwise, automation simply produces security findings at machine speed. The backlog will be delighted.

Train With the Pipeline Running

DevSecOps is difficult to learn from diagrams alone.

A stronger exercise gives participants source code, a CI/CD pipeline, automated tests, container builds and a deployment environment. Introduce an insecure dependency or configuration, then ask learners to identify where the control should catch it and what should happen next.

Let them change the pipeline, run another build and see the result.

That practical loop fits the learning approach at ITSEC Cyber & AI Academy. Cybersecurity professionals can build technical capability around application security, testing and secure delivery by working with systems that behave like the environments they’ll encounter on the job.

A vulnerability report tells a team what went wrong once.

DevSecOps skills help them change the process that allowed it through.

Explore hands-on cybersecurity and AI learning at ITSEC Cyber & AI Academy.

References

  1. NIST NCCoE, “New NIST NCCoE Resources on DevSecOps and October 28 Webinar on Agentic AI,” 24 September 2026
  2. NIST NCCoE, “Secure Software Development, Security, and Operations (DevSecOps) Practices Live Document,” 24 March 2026, updated on a rolling basis
  3. NIST NICE, “NICE Releases NICE Framework Components v2.2.0,” 28 April 2026
Share this post

You may also like

What CISOs Should Ask Before Choosing a Penetration Testing Provider in 2026
Cybersecurity

What CISOs Should Ask Before Choosing a Penetration Testing Provider in 2026

INTRODUCTION What percentage of your last penetration test report was actually proven exploitable, and what percentage was a list of things a scanner flagged and nobody validated? Most CISOs cannot answer that question with confidence, and that is exactly the problem. Buyers guides published this year point to a pattern worth sitting with. If a quoted penetration test comes in at four to five thousand dollars or less, it is very likely an automated vulnerability scan wearing a pen test label, not manual work performed by a skilled tester. That gap between what is sold as a penetration test and what is actually delivered is why the selection conversation matters so much more than most procurement teams treat it. ITSEC Asia, Indonesia's leading cybersecurity company, works with organizations across Indonesia, Singapore, Australia, and the UAE that have gone through this exact evaluation, and the questions that separate a genuinely useful engagement from an expensive checkbox exercise are more specific than most RFPs ever ask. Source: Six Questions to Ask a

ITSEC AsiaITSEC Asia
|
Jul 17, 2026 — 5 minutes read
Why Threat Hunting Is the Only Way to Stop Attackers Who Are Already Inside
Cybersecurity

Why Threat Hunting Is the Only Way to Stop Attackers Who Are Already Inside

INTRODUCTION Here is a question every security leader should sit with: if an attacker entered your network six months ago, would you know? According to IBM's Cost of a Data Breach Report 2024, the average time to identify a breach now stands at 194 days, nearly half a year of undetected attacker activity operating freely within enterprise infrastructure. Prevention tools, no matter how sophisticated, have already demonstrated they cannot close that window on their own. Firewalls, antivirus software, and multi-factor authentication are necessary. They are not sufficient. The organizations that understand this distinction are the ones investing in threat hunting: the proactive, intelligence-driven practice of searching for adversaries who have already bypassed the perimeter and are operating in silence. ITSEC Asia, the cybersecurity leader in Indonesia with operations across Singapore, Australia, and the UAE, works with organizations across these regions to build this exact capability before the next breach makes it urgent. Sources: IBM Cost of a Data Breach Report 2024 [https://www.ibm.com/reports/data-breach] THE GAP THAT REACTIVE SECURITY CANNOT CLOSE The fundamental flaw in

|
Mei 12, 2026 — 5 minutes read
A SOC Can’t Detect What It Never Learned to See
Cybersecurity

A SOC Can’t Detect What It Never Learned to See

A security alert arrives. An analyst opens it, checks the surrounding activity and begins reconstructing what happened. That sounds like the beginning of detection work. In reality, a considerable amount of work happened earlier. Someone decided which events should be logged, configured the systems to produce them, collected those records centrally and made sure the data contained enough detail to support an investigation. If that work is poor, even an excellent analyst is starting with missing pages. An upcoming ITU cybersecurity exercise in Dushanbe makes this dependency unusually explicit. During the three day program from 21 to 23 September 2026, teams will configure centralized monitoring and telemetry collection before responding to simulated ransomware, data exfiltration, server compromise and command and control traffic. The methodology has a catch: performance against attacks on Day 3 depends on the monitoring participants configured on Day 2. That’s a useful model for SOC training. VISIBILITY IS A SKILL SOC development often concentrates on the visible part of the job: analysing alerts, threat hunting and incident response. Those capabilities

ITSEC AsiaITSEC Asia
|
Sep 17, 2026 — 3 minutes read

Receive weekly
updates on new posts

Subscribe