This article summarises a video interview and conference session by Tim Mackey, technical evangelist for Black Duck by Synopsys (now a Synopsys business unit), conducted by JAXenter editor Gabriela Motroc at DevOpsCon 2018. The original source is jaxenter.com.
Why Traditional AppSec Fails in a DevOps World
Traditional application security was designed around a clear perimeter: harden the boundary, scan before release, and trust what is inside the wall. That model breaks down in modern software delivery. Continuous integration and continuous delivery (CI/CD), containerisation, cloud-native architectures, and heavy reliance on open source components all dissolve the concept of a stable perimeter. Worse, they accelerate the pace at which code moves from a developer’s laptop to production — often in hours rather than months.
The core tension is straightforward: DevOps teams prize speed and agility. Security gates that halt pipelines or demand lengthy manual reviews are simply skipped, worked around, or deprioritised. The only sustainable answer is to integrate security directly into the DevOps process itself rather than bolting it on at the end.
Key Application Security Challenges as DevOps Matures
According to Tim Mackey, the biggest security challenge in a DevOps environment is developing a clear picture of your overall information flow. That means answering three questions continuously:
- What data moves through your system, and where does it go? Understanding data flow is a prerequisite for identifying what needs protecting and from whom.
- What are the actual security risks at each stage? Risk profiles differ between development, staging, and production environments, and between in-house code and third-party or open source components.
- What is the highest-priority problem right now? Not every vulnerability requires immediate action. Triage based on exploitability, data sensitivity, and regulatory exposure is essential.
Mackey also highlighted that regulations such as GDPR raise the stakes for security failures. A data breach is no longer just a reputational event — it carries direct regulatory and financial consequences, which changes how organisations should weigh the cost of fixing a known vulnerability against the risk of leaving it unaddressed.
Why Building AppSec Into DevOps Matters
When security is not embedded in the DevOps workflow, teams discover vulnerabilities late — often after a component with a known flaw has been deployed to dozens of environments or integrated into a customer-facing product. The later a vulnerability is found, the more expensive it is to remediate: code must be traced back through builds, containers must be re-imaged, and dependent services must be re-tested.
By contrast, integrating security tooling directly into CI/CD pipelines — through software composition analysis (SCA) for open source dependencies, static analysis for in-house code, and container image scanning — surfaces issues at the point where they are cheapest to fix: during development. Teams get actionable feedback without leaving their existing toolchain, and security becomes a quality gate rather than a separate process.
Open Source Risk: Three Trends from the Black Duck Report
Mackey referenced findings from a Black Duck report (released in the months prior to DevOpsCon 2018) that identified three dominant trends in how organisations interact with open source software:
- Open source is the default. The overwhelming majority of commercial applications contain a significant proportion of open source code. This is not a niche practice — it is how modern software is built.
- Security engagement with open source communities is lagging. Organisations consume open source components at scale but rarely participate in the communities that maintain them. They receive the benefits but contribute little to the security health of those projects.
- Open source licence compliance is becoming a competitive and legal concern. Organisations are becoming more aggressive about auditing which licences govern the components they ship, particularly as legal teams and regulators pay closer attention.
The headline takeaway Mackey drew from these trends: organisations need to be not just consumers of open source, but active participants in the communities whose components underpin their products.
Should You Stop Using Open Source When Flaws Are Found?
A common instinct when a vulnerability is discovered in an open source component is to rip it out and replace it with an alternative. Mackey pushed back on this reaction. In practice, the replacement is often a fork of the same underlying codebase — carrying the same history, the same architectural decisions, and potentially the same flaws. Switching libraries is not the same as eliminating risk.
The more productive response is to:
- Report the vulnerability to the project maintainers and, where relevant, to a vulnerability database such as the National Vulnerability Database (NVD).
- Trace where your organisation obtained the component — directly from the upstream project, from a package mirror, or via a vendor — so that you can monitor when a patched version becomes available.
- Engage with the upstream community rather than treating the project as a black box. Organisations that contribute to open source security reviews, fund maintainers, or submit fixes directly strengthen the ecosystem that their own products depend on.
“Through the community engagement, we all win.”
Tim Mackey, Technical Evangelist, Black Duck by Synopsys — DevOpsCon 2018
Container Security: Immutability, Ephemerality, and Disclosure
In his DevOpsCon 2018 session, Mackey addressed the security characteristics of containers specifically. Two properties define the container model and directly affect how security must be applied:
- Immutability. Containers are built once from an image and run as many identical instances as needed. You do not patch a running container in place — you rebuild the image and redeploy. This is a security advantage when enforced correctly, but it means that vulnerable base images propagate into every instance until the image itself is updated.
- Ephemerality. A container should live only as long as it is needed. Orchestration systems may terminate containers without warning. Security controls that assume persistent processes or file systems do not translate cleanly to containerised workloads.
Mackey predicted that the rate of public security disclosures would continue to rise — a trend that has proved accurate in subsequent years as the attack surface of modern applications has expanded. He also highlighted that web service APIs introduce distinct risk profiles that teams need to account for, including:
- Disruption or discontinuity of service from a third-party API provider
- Loss of intellectual property through unintended data exposure
- Data breaches via poorly secured API endpoints
- Unintended reliance on unreliable or unmaintained external services
Not every external API or service can be trusted implicitly. Teams should treat third-party service dependencies with the same scrutiny they apply to open source library dependencies.
The Researcher Mindset: Report What You Find
Mackey closed his session with a call to action that reframes how engineers should think about their role. Every developer and operator who interacts with open source components is, in a meaningful sense, a security researcher. When you encounter unexpected behaviour, an undocumented API response, or a potential flaw in a library you depend on, you are in a position to act on that information in a way that benefits the entire community.
Responsible disclosure — reporting findings to maintainers, coordinating with security teams, and contributing to public vulnerability databases — is not an activity reserved for dedicated security professionals. It is a practice that any engineer can and should participate in. The cumulative effect of many teams reporting and engaging is a measurably more secure open source ecosystem for everyone.
Practical Takeaways for DevOps Teams
- Integrate security tooling into your CI/CD pipeline. Software composition analysis, static analysis, and container image scanning should run automatically on every build, not as a periodic manual audit.
- Maintain an accurate software bill of materials (SBOM). Know exactly which open source components — and which versions — are present in every artefact you ship.
- Monitor for new disclosures. A component that was safe when you added it may become vulnerable next week. Automated alerting against vulnerability feeds is essential.
- Engage with upstream communities. Report bugs, review security advisories, and where possible contribute fixes. Your organisation benefits directly from the health of the projects you depend on.
- Treat container images as code. Keep base images updated, scan images in your registry as well as at build time, and enforce immutability policies in your orchestration layer.
- Evaluate third-party API dependencies critically. Assess the reliability, security posture, and data handling practices of every external service your application calls.