Skip to content

AppSecEU 16 - Rob van der Veer - Grip on SSD - Dutch government standard for outsourcing secure

Rob van der Veer

AppSecOWASP Foundation39 minIntermediateOpen on YouTube ↗

Security researchers examine technical aspects of AppSecEU 16 - Rob van der Veer - Grip on SSD - Dutch government standard for outsourcing secure.

Summary

### Overview In this AppSecEU 2016 presentation, Rob van der Veer (Principal Consultant at Software Improvement Group, or SIG) introduces "Grip on Secure Software Development" (Grip on SSD). Developed in collaboration with the Dutch government's Center for Information Security and Privacy Protection (CIP), system integrators (such as IBM, Centric, Sogeti), and SIG, the standard provides an open framework for clients and suppliers to collaborate effectively on building secure software without dictating the supplier's internal development process. The talk also marks the international launch of the standard, celebrating its English translation and ongoing efforts to establish it as an OWASP project.

### Key Topics - **The Danger of Haste and Common Outsourcing Pitfalls**: Organizations frequently rush software delivery, causing security to become an afterthought ("security by add-on"). Common industry quotes illustrate recurring issues: clients assume suppliers know how to build secure software without contractual obligations; requirements are vague (e.g., "comply with OWASP"); patching responsibilities are omitted; developers create risky self-made crypto; requirements are copy-pasted across projects without tailoring; developers are unaware of business risk context; and accepted risks are never re-evaluated. - **Over-Reliance on Late Testing and Tools**: Clients frequently rely entirely on penetration testing and automated scanning tools as a panacea. Van der Veer notes that fixing flaws late in production costs roughly 100 times more than addressing them early, dynamic testing misses architectural weaknesses, and automated tooling only catches a fraction of code vulnerabilities. He also highlights a common avoidance of direct source code review due to its daunting nature (e.g., Heartbleed in OpenSSL or the Belgian electronic voting system release). - **The "Comply or Explain" Principle**: Decision-makers from participating organizations sign a manifest agreeing to a common ground standard using a "comply or explain" model. This allows flexibility—enabling suppliers or government departments (like the Ministry of Defense) to use alternative methodologies when justified—while fostering continuous dialogue and eliminating rigid liability obstacles.

### Technical Details & Methodology - **Core Components**: Grip on SSD delivers a comprehensive method handbook featuring a maturity model, standardized baseline requirements, verification guidelines, tester training slides, and contract templates. - **Requirement Specification (SURF/CIP Style)**: Requirements are structured to define what is needed, why it matters, the associated risk, and mappings to standards (such as ISO 25010), while keeping definitions non-technical so both business clients and technical suppliers stay aligned. - **Right Level of Abstraction**: The framework advises against trying to make security requirements exhaustive or overly technical. Instead, it sets the right baseline (e.g., data confidentiality and secure transport) without micromanaging low-level implementation details (such as specific framework cache disposal on crashes). - **Verification Mix & Code Quality**: Grip on SSD advocates for product verification rather than solely auditing processes (e.g., OpenSAMM, BSIMM). Van der Veer presents an assessment mix based on research and SIG experience showing that across top security risks: four are typically identified via manual secure code review, two via improving code maintainability (reducing complex logic that leads to security errors), one via automated static analysis, and one via penetration testing. - **Privacy and Maintainability**: Manual inspection must extend beyond basic vulnerability hunting to inspect actual data deletion logic (referencing the Ashley Madison breach) and ensure software maintainability, preventing convoluted code from causing systemic security flaws.

### Takeaways To achieve security by design, organizations should establish a baseline set of security requirements, institute mandatory risk and threat analyses for every IT project, adapt contract templates with early external code review clauses, track application portfolios via dashboards, and adopt a balanced, risk-driven verification strategy.

Related talks