Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building a SSDLC @ Mercari

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.

Azeem Ilyas

April 20, 2022

Other Decks in Technology


  1. Azeem Ilyas Product security engineer Interests Snowboarding, Hacking, Reverse Engineering,

    Embedded devices, VR, Games and Pixel Art @TheAxZim /in/azeem-ilyas
  2. Development flow at Mercari Where are the weak points in

    the SDLC? An overview of our solutions AGENDA
  3. A typical development flow Strategy PMs can sometimes come up

    with not-so-safe features or even entire projects.
  4. A typical development flow Design Engineers design’s are potentially insecure.

    Big focus + incentive on functionality & UX, not security.
  5. A typical development flow Development Insecure code Use of vulnerable

    libraries Secrets pushed to repositories Insecure CICD pipeline
  6. A typical development flow Testing Lack of resource from Security

    team. Lack of (automated) e2e tests relating to security features.
  7. 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.
  8. 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.
  9. 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
  10. 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
  11. Known mostly as a SCA tool. SCA = Software Composition

    Analysis Simply: Analyzes your dependency tree for vulnerable dependencies. WhiteSource
  12. <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
  13. 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.
  14. • 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
  15. • 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
  16. 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.
  17. • PaaS for mobile device virtualization • Runs natively on

    ARM servers • Testing capabilities ◦ Data storage ◦ System calls and network traffics ◦ Frida console ◦ XCode & ADB support
  18. • 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
  19. 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.
  20. 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.
  21. 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)
  22. 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.
  23. 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.
  24. - 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