Building a SSDLC @ Mercari

Myself and Eli cover the tools and techniques that Mercari uses in every day development in order to secure our SDLC.

Transcript

1. Building a SSDLC @ mercari 19:15 - 19:45
2. Azeem Eli
3. Azeem Ilyas Product security engineer Interests Snowboarding, Hacking, Reverse Engineering, Embedded devices, VR, Games and Pixel Art @TheAxZim /in/azeem-ilyas
4. Shaokang Sun (@Eli) Product security engineer Interests Hacking, Soccer, Video Games, Board Games
5. Development flow at Mercari Where are the weak points in the SDLC? An overview of our solutions AGENDA
6. SDLC = SOFTWARE DEVELOPment LIFE CYCLE SSDLC = SECURE SOFTWARE DEVELOPment LIFE CYCLE
7. A typical development flow Strategy PMs can sometimes come up with not-so-safe features or even entire projects.
8. A typical development flow Design Engineers design’s are potentially insecure. Big focus + incentive on functionality & UX, not security.
9. A typical development flow Development Insecure code Use of vulnerable libraries Secrets pushed to repositories Insecure CICD pipeline
10. A typical development flow Testing Lack of resource from Security team. Lack of (automated) e2e tests relating to security features.
11. A typical development flow Launch Security testing is left until a week before full release. Not always clear indicators whether a release can be blocked or not.
12. A typical development flow Maintenance Libraries become old and vulnerabilities are found.
13. Planning + Design stage Security Awareness Training ➡ Gives engineers + PMs an idea of what not to do in general. ➡ Teach them to dedicate a section of their time to security considerations.
14. Security Champion Programme ➡ Teach Engineers to think like a hacker. ➡ Build an army of security engineers. ➡ Engineers become more proactive in Security and find problems much earlier. Security team can retire. Planning + Design stage
15. Threat Modelling ➡ Covered by @Gloria in the next presentation. ➡ Engineers+PMs build a security mindset and brainstorm issues early on in the life cycle. Planning + Design stage Svc
16. SECURITY TEAM CAN’T BE EVERYWHERE
17. An overview of our solutions
18. WhiteSource Used In
19. Known mostly as a SCA tool. SCA = Software Composition Analysis Simply: Analyzes your dependency tree for vulnerable dependencies. WhiteSource
20. <REPO> Github App Unified Agent (CircleCI / Actions) + Integrates with 1 simple PR + Simple to use, Highly Configurable + Issues in Github + auto-resolving - Doesn’t provide transparency - Slow on large repositories + Highly Configurable + Full Logs in the case of issues + You specify the container + Faster for larger repositories - More complicated to integrate - Issues not in Github, have to use the Whitesource dashboard
21. https://circleci.com/developer/orbs/orb/whitesource/ whitesource-scan https://github.com/mercari/Whitesource-Scan-Action ORB GITHUB ACTIONS
23. +1 – Can be used for license policis
24. Typical workflow: Developers fix issues as they are raised for Whitesource. Block release if any issues are left unaddressed. Whitesource will continue to raise issues periodically, the security team will frequently review high/critical issues throughout the organization and push teams to keep their repositories in a healthy state.
25. CODEQL Used In
26. • Variant Analysis ◦ Using a known security vulnerability as a seed ◦ Iterate over the query • CodeQL Analysis Steps ◦ Prepare the code by setting up a database. ◦ Run CodeQL queries against the database. ◦ Interpret the query results. • Supporting Languages ◦ C/C++, C#, Golang, Java, JS/TS, Python, Ruby True
27. Reference
28. • How we implemented it ◦ GitHub workflows ▪ Internal dependencies ▪ Web hooks and token generator ◦ GitHub dashboards ▪ Alert by type and risk level ▪ Processes for closing an alert
29. • Proof of Concept: GoVWA
30. • Proof of Concept: GoVWA
31. • Proof of Concept: GoVWA
32. Typical workflow: Security team sends bulk pushes of GitHub workflows including CodeQL to each repo. Developers fix issues as they are raised by CodeQL’s auto-scan on new merges. Developer could check the details and either raise an issue on GitHub or dismiss it as a False-Positive . CodeQL will continue to scan codes and raise issues periodically, where the security team can follow the issues from GitHub security dashboard.
33. CORELLIUM Used In
34. • PaaS for mobile device virtualization • Runs natively on ARM servers • Testing capabilities ◦ Data storage ◦ System calls and network traffics ◦ Frida console ◦ XCode & ADB support
35. • Case study
36. BURP SUITE ENTERPRISE Used In
37. • Security tests integrated with SDLC • Scanning feature ◦ OAST & Trusted test cases ◦ Recurring scans ◦ Scalable scans • Integration features ◦ CI/CD platform ◦ REST & GraphQL API ◦ Burp extension
38. • Case study
39. Typical workflow: For each products before release, Security team configures Burp Enterprise with an entry URL and a custom configuration file. Burp Enterprise will automatically run and detect issues. Issue can be seen from Burp Enterprise dashboard, and could also be exported to other vulnerability management tools such as JIRA.
40. NOWSECURE Used In
41. SAST and DAST tool for Mobile Simply: Takes your builds (APKs and IPAs) and analyzes them for security issues. Running simple SAST checks on just the repositories is not enough. Mobile builds can be complicated and because of the many different ways to do things on Android and iOS, it’s much easier to analyze the final builds themselves.
42. Before: + Its free… and open source. - Rules are regex based - Have to maintain your own MobSF server + secure it - Not built for CICD by design - We did lots of hacking on it to get it to work but then upstream would break something + There is now a CICD tool (MobSF/mobsfscan)
43. FROM THIS…
44. curl -v -X POST --data-binary @app.apk -H "Authorization: Bearer ${API_TOKEN}" \ https://lab-api.nowsecure.com/build/ To THIS… Reporting handled on Web UI. Alert integrations / JIRA integrations directly on NowSecure. No longer have to maintain an entire service.
45. Typical workflow: Runs in CI – against the main branch as a scheduled workflow (daily/weekly jobs) -> Gives us lots of chances to block releases before the main branch is split off into a release branch.
46. Insecure Code Vulnerable Dependencies Secrets pushed to repositories Insecure CI CD E2E Security Testing SUMMARY
47. - Still doesn’t capture everything in the SDLC - A few in-house tools that we’ve built as well which we’ve not mentioned here - Just these few tools/techniques themselves give us good coverage and the ability to block if necessary SUMMARY
48. Thank you for listening!