devopsy.kinsta.cloud

Tag: penetration testing

Why CI/CD Security Testing Is Going Autonomous (and Why It Should Stay Local)

Continuous integration and delivery changed the tempo of software. Teams merge dozens of times a day, infrastructure is redefined on every commit, and a new build can reach production in minutes. Security testing never caught up with that tempo. It still lives in two modes that both fight the pipeline instead of moving with it.

The first mode is the scanner. Static analysis, dependency checks and dynamic scanners run on every build, and they are useful, but they mostly report potential issues. A SAST tool flags a pattern. A dependency scanner flags a known CVE in a package you may never call. The result is a long queue of findings that a human still has to triage, and alert fatigue quietly becomes the real vulnerability.

The second mode is the penetration test. A skilled human, or a firm, probes the application, chains weaknesses together and confirms what is actually exploitable. The output is trustworthy, but it is a snapshot. It happens once or twice a year, on a version of the system that has already changed by the time the report lands. In a pipeline that ships continuously, a point in time assessment is structurally behind.

So the pipeline has fast tooling that produces noise, and slow expertise that produces proof, and nothing that gives you both at the cadence of your merges. That gap is exactly where autonomous testing is arriving.

What Autonomous Testing Actually Means

Autonomous does not mean another scanner with a chatbot bolted on. It means agents that reason about a target the way a tester does. They enumerate, form a hypothesis, try to exploit it, and only report the finding once they have proven it with a working exploit and the raw evidence behind it. The unit of output is not a maybe. It is a demonstrated attack path.

That shift matters for CI/CD for two reasons. First, proof of exploitation collapses the triage queue. If a finding arrives with the exact request, the response and the resulting access, there is nothing to reproduce and nothing to argue about. You fix it or you accept it, and you do that in minutes rather than in a backlog. Second, agents chain. Real breaches are rarely one bug. They are a leaked secret that unlocks a cloud role, a server side request that reaches a metadata endpoint, a misconfigured registry that yields a token. A scanner sees each of these in isolation. An autonomous agent walks the chain, which is the only view that reflects how attackers actually operate.

Why it Fits the Pipeline and the Supply Chain

The modern attack surface is not just the app. It is the pipeline itself and everything the pipeline touches. Secrets committed to git history. Infrastructure as code that quietly grants a wildcard permission. A container image with a forgotten backdoor. A CI runner with credentials that reach production. These are supply chain problems, and they change on every commit, which is precisely the cadence that periodic testing cannot serve.

Autonomous testing that runs inside or alongside the pipeline can look at each of these on every meaningful change. Not a quarterly audit of the supply chain, but a continuous one, with the same proof based output. That is the promise, and it is a real one.

The Blocker Nobody Likes to Say Out Loud

There is a catch, and it is the reason many teams have kept AI security testing at arm’s length. To reason, most autonomous tools send your data to a model they do not control. Your internal IP addresses, your hostnames, sometimes your credentials and your source code travel to a cloud endpoint so the model can think about them.

For a lot of organizations that is simply not allowed. A bank, a hospital, a defense supplier or any operator of critical infrastructure cannot ship internal topology and secrets to a third party. Compliance forbids it. Client contracts forbid it. In some sectors the law forbids it. And even where it is technically permitted, sending production data to an external model is a risk many security teams are right to refuse. So the most capable new testing approach ends up locked out of the environments that need it most.

Why it Has to Stay Local

The way through is not to abandon autonomous testing. It is to make it run without your data ever leaving. Two ideas make that practical.

The first is running the reasoning model locally. Open weight models are now good enough to drive this kind of work on hardware a team can own, which means the intelligence lives inside your boundary instead of on someone else’s servers.

The second is tokenization at the boundary. Before anything reaches a model, real values are replaced with deterministic placeholders. An IP becomes a stable token, a hostname becomes another, and the model reasons over the structure without ever seeing the real thing. The real values are reinjected locally, for the moment a tool actually runs, then masked again on the way back. Done properly, this is compatible with air gapped setups and leaves no path for exfiltration.

Put together, local reasoning and boundary tokenization turn autonomous testing from something the security team has to veto into something they can actually deploy in the pipeline.

How to Evaluate it for Your Own Pipeline

If you are looking at this category, a few questions separate the real thing from the demo. Does every finding come with proof of exploitation, or just a severity score.? Where does target data go, and can the whole thing run without any external call? Are the results reproducible, so a developer can rerun the exact path? And is the methodology open enough to audit, because a black box making claims about your security is its own risk?

Autonomous security testing is going to become part of CI/CD the same way automated testing did. The teams that adopt it early will trade a quarterly snapshot for continuous, proof based coverage. But the version that lasts in the enterprise will be the one that keeps your data on your own machines. Autonomous is what makes it fast enough for the pipeline. Local is what makes it safe enough to allow.

Mehdi Boutayeb is co-founder of ASC-IT and works on Darkmoon, an open source autonomous penetration testing platform. He previously worked as an engineer at Airbus.

August 12, 2026
Continuous Security in DevSecOps: Moving Beyond One-Time Testing
Waiting for a single annual pentest to secure your application is like locking your front door only once a year and hoping for the best. In an era where 133 new vulnerabilities are reported every single day, relying on periodic snapshots leaves your organization exposed to evolving threats for months at a time.

This approach is no longer just risky; it is a significant financial liability. Data from the IBM Systems Science Institute highlights that fixing a bug in production costs 100 times more than catching it during the initial design phase. For modern teams, the ‘window of vulnerability’ between tests is where attackers find their greatest opportunities.

Transitioning to continuous security in DevSecOps is the only way to close this gap. By embedding automated validation into your CI/CD pipeline, you move from a reactive ‘checkbox’ mentality to a proactive, resilient posture. This guide explores how to move beyond one-time testing to build a defense that evolves as fast as your code.

What is Continuous Security in DevSecOps?

Continuous security in DevSecOps means integrating security checks into every stage of the software development life cycle. It is not a one-time audit. It runs alongside your code, from the first commit to production deployment.

Traditionally, security testing happened at the end. That model does not work anymore. With faster release cycles, vulnerabilities left unchecked for weeks can cost companies an average of $4.44 million per breach, according to IBM’s 2025 report.

In DevSecOps, security becomes part of the pipeline itself. Automated scanning, real-time threat detection and policy enforcement run continuously. Every build gets checked. Nothing waits for a quarterly review.

The Problem With One-Time Security Testing

Most teams still treat security like a final checkbox. You build the product, hand it over to the security team and wait for a report. That process made sense 10 years ago. It does not make sense now.

Release cycles have shortened dramatically. Teams ship code daily, sometimes multiple times a day. A penetration test done once a quarter cannot keep up with that pace. New vulnerabilities get introduced with every pull request.

The numbers back this up. According to Veracode, 76% of applications have security flaws on initial scan. Most of those flaws come from code written between testing cycles. That gap is where attackers operate.

One-time testing also creates a false sense of security. You pass the audit, check the box and assume you are covered. But your attack surface keeps changing. Static snapshots of security do not protect dynamic, constantly evolving systems.

Core Principles of a Continuous Security Model

Building continuous security is not about adding more tools. It is about changing how security fits into your entire development process. These five principles form the foundation of that shift.

1. Automate Security at Every Stage

Manual reviews cannot scale with modern development. Automated security checks need to run at every stage of your CI/CD pipeline. From code commit to deployment, automation catches issues before they reach production. It removes the human bottleneck without removing human judgment.

2. Shift Security Left Without Abandoning the Right

Shifting left means catching vulnerabilities early in development. But security cannot stop there. Runtime monitoring, post-deployment scanning and incident response all matter just as much. A strong continuous security model covers the full software delivery life cycle (SDLC), not just the beginning of it.

3. Treat Security as a Shared Responsibility

Security is not just the security team’s job. Developers, DevOps engineers and product teams all play a role. When everyone understands their part, vulnerabilities get caught faster. Building a security-aware culture is just as important as any tool you deploy.

4. Integrate Threat Intelligence in Real-Time

Static threat models go stale fast. Continuous security means feeding real-time threat intelligence into your pipeline. When new vulnerabilities are disclosed, your system should respond immediately. Waiting for the next scheduled review gives attackers a window they will use.

5. Measure, Monitor and Improve Continuously

You cannot improve what you do not measure. Track metrics such as mean time to detect, vulnerability closure rate and false-positive rates. Regular review of these numbers tells you where your security program is strong and where it needs work. Continuous improvement is the goal.

How to Integrate Continuous Security in DevSecOps

Integrating continuous security into DevSecOps is not a one-day project. It is a step-by-step process that embeds security controls directly into your development and deployment workflows.

Step 1: Audit Your Current Pipeline

Before adding anything new, understand what you already have. Map out every stage of your CI/CD pipeline and identify where security checks are missing or manual. This gives you a clear picture of your gaps before you start filling them.

Step 2: Embed SAST DAST Early

Static application security testing (SAST) should run on every code commit. Dynamic application security testing (DAST) should follow in your staging environment. Running both consistently means vulnerabilities get caught at the source, not weeks later during a scheduled review.

Step 3: Automate Dependency Scanning

Third-party libraries are one of the biggest sources of risk. Use software composition analysis (SCA) tools to automatically scan dependencies with every build. Tools like Snyk or Dependabot flag known vulnerabilities in open-source components before they make it into production.

Step 4: Secure Your CI/CD Configuration

Your pipeline itself is an attack surface. Harden your CI/CD configuration by enforcing least-privilege access, securing environment variables and auditing pipeline scripts regularly. A compromised pipeline can undo every other security control you have put in place.

Step 5: Add Runtime Security Monitoring

Security does not stop at deployment. Implement runtime protection tools that monitor application behavior in production. Solutions such as Aqua Security and ZeroThreat.ai can detect anomalous activity and trigger alerts the moment something unusual happens in your live environment.

Step 6: Set Security Gates in the Pipeline

Define clear pass/fail criteria for security checks. If a build introduces a critical vulnerability, it should not move forward. Security gates enforce standards automatically and remove the pressure of manual judgment calls during fast-moving release cycles.

Step 7: Improve Continuously

Continuous security never truly ends. Schedule regular reviews of your security metrics, tooling and policies. As your application evolves, your security posture needs to evolve with it. Treat it like any other part of your engineering process, always improving.

Top DevOps Tools for Continuous Security

Selecting the right tools is the foundation of a successful continuous security strategy. You need solutions that not only find vulnerabilities but also integrate smoothly into your existing development workflows without causing delays.

Here are the best picks for ensuring security right from your CI/CD pipelines:

1. Burp Suite

Burp Suite is a widely used web application security testing platform known for its strong manual penetration testing capabilities. It works as an intercepting proxy, allowing testers to analyze and modify HTTP and HTTPS traffic to uncover vulnerabilities in real-time.

It supports the full testing workflow, from mapping the attack surface to identifying complex vulnerabilities. While it includes automated scanning, it is mainly preferred for deep, expert-driven testing where precision, context and detailed validation are required.

Key Features of Burp Suite:
- Intercepting proxy for HTTP and HTTPS traffic analysis
- Advanced vulnerability scanning and crawling
- Intruder tool for fuzzing and attack simulation
- Repeater for manual request testing and validation
- Session handling and authentication testing
2. OWASP ZAP

OWASP ZAP is an open-source web application security scanner designed for both beginner and experienced teams. It provides automated vulnerability scanning along with proxy-based testing, making it a flexible tool for integrating security into development workflows.

It is widely used in DevSecOps environments because of its automation capabilities and CI/CD compatibility. ZAP performs both passive and active scanning, helping teams detect common vulnerabilities continuously without requiring heavy manual effort.

Key Features of OWASP ZAP:
- Automated passive and active vulnerability scanning
- REST API support for CI/CD integration
- Intercepting proxy for traffic inspection
- Scriptable interface for custom testing
- Strong community support and extensions
3. ZeroThreat.ai

ZeroThreat.ai is a modern, AI-powered automated penetration testing platform. It supports the DevSecOps approach with simplified CI/CD integration. The tool simulates real attacker behavior to identify exploitable vulnerabilities across web applications and APIs, going beyond traditional vulnerability scanning.

It focuses on continuous validation by chaining vulnerabilities, testing business logic and running security checks across staging and production. This helps teams identify real risk exposure and maintain strong security posture without slowing down release cycles.

Key Features of ZeroThreat.ai:
- Agentic attack path simulation for real-world testing
- Exploit chaining and business logic vulnerability detection
- Continuous, production-safe automated pentesting
- CI/CD integration for ongoing security validation
- AI-driven risk prioritization and remediation insights
4. Mend

Mend is a software composition analysis platform designed to secure open-source dependencies across the development life cycle. It helps teams detect vulnerabilities, license risks and malicious packages early, directly within developer workflows and CI/CD pipelines.

It stands out with reachability analysis, which focuses on exploitable vulnerabilities instead of noise. Mend also provides real-time alerts and automated remediation, allowing teams to fix issues faster while maintaining visibility into software supply chain risks.

Key Features of Mend:
- Advanced reachability analysis for real risk detection
- Automated vulnerability remediation workflows
- Open-source dependency and license compliance scanning
- SBOM generation and supply chain visibility
- CI/CD and IDE integrations for continuous security
5. Semgrep

Semgrep is a lightweight static analysis tool that helps developers find security vulnerabilities directly in source code. It supports multiple languages and integrates easily into CI/CD pipelines, making it a strong choice for continuous code security testing.

It uses rule-based semantic analysis, allowing teams to customize detection logic based on their codebase. With support for SAST, SCA and secrets detection, Semgrep enables fast and flexible security checks without slowing development workflows.

Key Features of Semgrep:
- Static application security testing with semantic analysis
- Custom rule creation for tailored vulnerability detection
- CI/CD and IDE integration for continuous scanning
- Multi-language support across modern stacks
- Combined SAST, SCA and secrets detection capabilities
6. Black Duck

Black Duck is an enterprise-grade application security platform focused on managing open-source and third-party risks. It provides deep visibility into dependencies, helping teams identify vulnerabilities, compliance issues and supply chain threats across the entire SDLC.

It combines multiple scanning techniques, including dependency, binary and snippet analysis, to detect hidden risks. With continuous monitoring and automated policy enforcement, Black Duck ensures secure software delivery at scale.

Key Features of Black Duck:
- Comprehensive SCA for open-source risk management
- Multi-layer scanning including binary and snippet analysis
- Continuous monitoring of dependencies and vulnerabilities
- SBOM generation and compliance tracking
- Integration across CI/CD pipelines and developer tools
7. Spectral

Spectral is a developer-first security platform focused on detecting secrets, misconfigurations and sensitive data exposure in codebases. It continuously scans code, logs and assets to prevent credential leaks and reduce security risks early.

It uses AI-powered detectors and integrates directly into CI/CD pipelines and pre-commit workflows. This allows teams to identify exposed API keys, tokens and sensitive data before they reach production environments.

Key Features of Spectral:
- Secrets scanning with thousands of built-in detectors
- Real-time detection of API keys, tokens and credentials
- CI/CD and pre-commit integration for early detection
- AI-powered risk detection across code and assets
- Custom rule creation for organization-specific policies
Wrapping Up

Security can no longer be treated as a final checkpoint. Modern DevOps teams deploy multiple times a day, and each release can introduce new risks. To tackle this, continuous security must be embedded for automating security testing, monitoring and validation into every stage of the life cycle. It ensures vulnerabilities are identified early, fixed faster and never left unnoticed as new deployments are made. This shift helps build a resilient security posture that keeps pace with fast-paced SDLC.
May 12, 2026
IBM Unveils Simulation Tool for Attacking SCM Platforms

At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

August 9, 2022
What Developers Really Think About Pentesting

A developer in their natural habitat is often spotted in a state of deep concentration, coding awesome features to tight deadlines. Feature-building is often our favorite part of the job, and really, it’s the fundamental outcome of the software development life cycle (SDLC).

However, as we have discussed before, many of us are still prioritizing features over security best practices. After all, in most organizations, it is set up to be someone else’s job and adequate security training for us is limited. Penetration testing and static analysis scanning tools (SAST) are just part of the overall process to mitigate security risks, operating rather independently from what we do — until the code bounces back to us for hotfixes, of course.

It’s at that moment that many developers think, “Do the pentesters hate me?”

These interactions often define a team and culture. The concerning thing is, the lack of communication, understanding and overall collaboration has created tension, at least on the side of the developer.

Think about it: Imagine you’ve spent a few hundred hours sculpting a marvelous statue, and then someone comes along with a hammer and starts smashing bits off it after they’ve told you its foundations are not up to scratch. That’s the perceived dynamic between a tester and developer — the latter has their software darlings slaughtered by an outsider that hasn’t labored through the process with them; instead, they’ve extended the workload and delayed the satisfaction of shipping code.

Having moved into the security space long ago, I can see both sides of the story. And no, pentesters don’t hate developers. The pentester is in all likelihood, overworked and under a lot of pressure. As such, a constant stream of common security bugs that could be quite easily fixed at the code level take up time, resources and headspace away from the really serious issues.

I always saw pentesters as kind of like parents. They want you to do well, and when you don’t they’re not mad, just disappointed.

Now that I’ve put that (perhaps slightly unfair) image in your mind, let’s explore this a little deeper. What has caused this world view among developers?

Resentment for Being Told What to Do

Nobody likes feeling as though they’ve done a bad job, or that someone doesn’t like their work. Sadly for developers, when static analysis and pentest results come back to them, it can feel like a report card. They’ve been given low grades, but at the end of the day, their bosses assess them on the features they’ve built and the time they’ve delivered them, not whether there were vulnerable elements in the software or not.

For the poor pentester, this is a case of “don’t shoot the messenger.” It’s nothing personal — they are tasked with finding bugs, and they found them. Granted, at a person-to-person level, maybe some pentesters are grumpier than others, but they’re not (or shouldn’t be) out to crucify development teams. It would be far easier for both teams if they were on the same page with what constitutes security best practice. Developers are not expected to be perfect; realistically, the testing team is there to protect them from shipping vulnerable code.

Minor Issues vs. Higher Priorities

It’s true, a developer’s highest priority will always be the building of features, and in this crazy world of rapid digitization, it will have to be done at speed. While some coders have a personal interest in security and secure coding, the general sentiment is that security is “someone else’s problem,” which inevitably includes pentesters.

Most common vulnerabilities are indeed minor issues to remediate — once known, the fixes are simple to execute for things like cross-site scripting (XSS) and SQL injection. The problem is, many developers don’t realize they’re introducing them in the first place, and these seemingly minor issues are the small window of opportunity an attacker needs to cause devastating problems for a company. According to Akamai, between November 2017 and March 2019, SQL injection vulnerabilities accounted for 65% of all web-based attack vectors. For a vulnerability that has had a known fix for more than 20 years, that is a sobering statistic.

Some pentest teams do assist in the remediation of security bugs, but others will provide a report of the bad news and expect developers to work through hotfixes, even if they have moved onto a different project by the time this happens. And in some cases, the development team may be faced with a report that includes bugs they can’t (or shouldn’t be expected to) fix. It still has to be part of the findings, and again, not taken personally.

The “happy medium” for this would be pentesters, security personnel and development managers acting in more of a mentor role to ensure the team has what they need in terms of effective training and tools, giving individual coders the best chance to succeed and code securely from the very beginning of the SDLC. Both teams really should be meeting half-way to ensure security is considered from the start, as part of a healthy DevSecOps practice.

Lack of Knowledge vs. False Positives

Static analysis is an element of the security process in the SDLC, and static analysis scanning tools (SAST) play a fundamental role. And yes, false positives are an issue with these and other types (DAST/IAST) of scanners. It’s an annoyance in what is already a slow process, requiring manual code review and putting pressure on both developers and pentesters alike. Pentesting personnel have taken time to meticulously set up custom rules to avoid inaccurate readings and provided company-specific guidance, yet some false readings slip through and end up in front of a head-scratching developer.

This process isn’t perfect, but the other problem is that many developers lack enough knowledge to mitigate a lot of common vulnerabilities on a consistent basis. With security training rare in tertiary education, and on-the-job training varying in its effectiveness, it stands to reason that there may be some overconfidence at play as well (and it’s not their fault, we as an industry need to get better at equipping them with what they need).

Remediation Tasks

Sometimes, there is an assumption by overworked engineers that pentesters are just hanging in the wings, waiting for the moment to strike by testing an application and raining on the development team’s parade. They are over-testing, they’re nitpicking, they’re creating extra work.

The only problem with that is they, too, are overworked (more so, in fact, the cybersecurity skills shortage is at dire levels and getting worse) and simply don’t have the time to test without reason. They are not the sole decision-makers in prioritizing testing; it could have been requested by senior leadership, a customer, as part of a security audit or even determined as a result of a bug bounty program.

For a developer, being pulled off current feature-building sprints to work on security fixes is annoying — especially if it’s not their work. Perhaps a previous team did the last update, or another vendor. However, security is everyone’s problem. That doesn’t mean every developer has to take ownership of security bugs as though they have made them all themselves, but they do need to come to the party in terms of security being a shared responsibility.

Where to from Here?

Sometimes, a mindset shift can be all it takes to make significant headway in solving a problem. We’ve talked about the rather frosty reaction a developer has to less than favorable pentest results, but what if they could turn it into a challenge? Perhaps they could think of the pentester as a friendly competitor; someone they can beat at their own game. After all, a security-aware developer that can eliminate common bugs as they write code is going to make their job much more difficult. By contrast, a developer with no focus on security is going to be comprehensively bested by their pentester counterparts when they can easily break their software.

Pentesters and developers may not be joined in harmony 100% of the time, but their relationship can be vastly improved when an organization addresses security as a key priority, and empowers teams with the right knowledge and tools to succeed — especially developers. It comes down to whether a company-wide, positive security culture is a priority, and if we are to fight the (currently) losing battle against common vulnerabilities, it absolutely should be.

June 17, 2020
DevOps need to pay more attention to security

Ty Miller, founder of Threat Intelligence, suggests organisations adopting DevOps need to pay more attention to security.

Over the last five years or so, the prevailing approach to IT security has changed – largely triggered by the activities of hacktivist groups such as Anonymous and LulzSec – and it is becoming an increasingly integrated part of the application lifecycle, he said.

The less attention given to security in the earlier stages, the more likely it is that the application will have to be rearchitected and redeveloped before deployment, which can be 100 times more costly than building in security from the outset.

Since DevOps is often adopted to allow more frequent code releases, it is important that security is built into the process from start to finish, as there is no longer time for extensive security testing between completion and release.

Part of the problem is that developers tend not to be security experts, and because of their backgrounds security officers generally are not application security specialists. This can leave a security gap, he said.

Miller’s recommendations include:

Code libraries The reuse of known-good code instead of reinventing the wheel each time reduces the risk of building new vulnerabilities into software.

Platform security While IT teams would not dream of omitting intrusion prevention systems and other security components from an on-premises system, “these sorts of things are quite commonly being left out” from cloud deployments possibly because they are thought to be insufficiently scalable – a symptom of the tendency to sacrifice security for flexibility. And organisations sometimes assume that SaaS products are secure, even though they can “become large scale data breaches.” Recent research suggests around 90 percent of SaaS offerings are not sufficiently secure for enterprise use, he said.

Automated builds Automatically building systems based on pre-hardened templates helps reduce the risk of accidentally overlooking something and other human errors. If you can be confident that a new server will spin up in a secure configuration, development teams can concentrate on the code they are working on.

Automated security testing Frequent releases are at odds with traditional security testing, such as engaging specialist penetration testers before a major release. “That’s thrown a spanner into the works,” Miller said. When do you do the security testing? Can you pinpoint everything that has changed since the last test, and focus testing efforts accordingly? “Automated security testing needs to be built into the DevOps process,” he advised.

Fortify, AppScan and Burp Suite are among the more reputable tools, he said.

HP’s Fortify http://www8.hp.com/us/en/software-solutions/application-security/ , a code review tool, “is very expensive [at up to $120,000 per year] but also very good,” according to Miller, even though it generates false positives as other tools do.

IBM’s AppScan http://www-03.ibm.com/software/products/en/appscan/ helps with web and mobile app development, and costs around $30,000 per year, he said. While it has a good feature set and a convenient GUI, it does need a lot of setting up and maintenance when it comes to workflows.

PortSwigger’s Burp Suite http://portswigger.net/burp/ is a semi-automated scanner for web applications. At $300 per seat it is relatively cheap, and “virtually every penetration tester around the world uses it,” said Miller. It might not be as intelligent as the big-name commercial products, but “it is a very accurate scanner.”

But automated testing is not a panacea. Automated scans can find perhaps 20 percent of vulnerabilities, but that’s 20 percent less for humans to find. And the output of such tools tends to include many false positives, so some expertise is needed to interpret the results – an inexperienced user can waste a lot of time, Miller warned.

For example, access control flaws can be hard to detect automatically. Does changing a number in a URL produce a different page in the same report, or a report for a different customer? Is any particular report public or private? A penetration tester understands the application and can easily decide whether or not there is a security issue, but the best an automated tool can manage is to warn there may be a problem here.

An organisation that has a defined set of methodologies covering the entire process from development to production, implements security as a baseline feature in code and infrastructure builds, uses automated scanning and security testing, and integrates regular penetration tests and reviews “will be significantly ahead of other organisations,” Miller suggested.

About the Author:

Stephen Withers is one of Australia¹s most experienced IT journalists, covering everything from gadgets to enterprise systems. In previous lives he has been an academic, a systems programmer, an IT support manager, and an online services manager. Stephen holds an honours degree in Management Sciences, a PhD in Industrial and Business Studies, and is a senior member of the Australian Computer Society. You can see his Linkedin profile here: http://au.linkedin.com/pub/stephen-withers/0/222/687/

January 20, 2015