How Ödeal uses Kondukto to jump-start their AppSec program

A customer story about creating an
AppSec program with Ödeal.

How to Create A Security Program From Scratch?

How to Create A Security Program From Scratch?

1

The Challenges

2

About Ödeal

3

The Situation

4

Our Approach

5

Results

The Challenges

  • Security was not baked into the softwaredevelopment lifecyclein a structured way. Security tools were randomly used by the software development teams at will.
  • Penetration testsperformed on a quarterly basis wereputting pressure on development teamsas the remediation of vulnerabilities was interfering with their development activities.
  • There wasno visibility into the vulnerabilities of applicationsand there was nosupervision of security metricsin the absence of a security engineer.

About Ödeal

Founded in 2014, Ödeal is theprovider of a payment technologythat allows subscribed businesses to receive payments by debit or credit cards using their mobile phones. Withmore than 68.000 subscribed businessesand a solid business model, the company has received funding in 2021 and has been growing its technology teams rapidly since then.

The Situation

As a rapidly growing fintech start-up with a growing tech team, Ödeal was in the midst ofrestructuring its CI/CD processes.

Due to the sensitive nature of business, security was a concern among the leadership team but with so much on developers’ plates, time could hardly be allocated tocreating a CI/CD pipelineintegrated with security tools.

There was a need for a platform wheresecurity testscouldeasily be integrated with CI/CD pipelineswhich could also provide visibility on the overall security posture of applications

Our Approach

  • 1As a first step,applicationsexisting on the ALM tool wereautomatically fetched to Konduktoafter integrating Kondukto with the ALM tool in minutes.
  • 2Based on the tech stack used in each application, the relevant open source security toolson Konduktowere configured and associatedwith relevant applications.
  • 3As Ödeal already had a git-flow branching mechanism in place,security testswere positioned inbetween feature and development branchesso that in each pull request, security tests could be triggered on open source security tools by Kondukto.
  • 4A company-wide script was written in such a way that if the repo was recently created on the ALM tool and not yet on Kondukto, it wasautomatically created through the CLI based on the hierarchyused by software development teams.
  • 5Leveraging the label-based automation capabilities of Kondukto,different automation policieswereappliedto applications with different labels (i.e. internal, external, GDPR).
  • 6PR decorationfunctionality of Kondukto CLI also allowed developers togain access to the vulnerabilitiesdiscovered in each PR on their ALM tool so that they were aware of the vulnerabilities before they advanced to further stages in the pipeline.

Results

  • Without spending a fortune on commercial security tools and even without having a security team at the company,the technical aspect of DevSecOps transition was easily achievedby writing a company-wide pipeline script that is used in all applications.
  • Thanks to this script, now any team that transitions to the new CI/CD pipelineautomatically has its projects onboarded to Kondukto and starts running pre-defined security testswithin the pipelinesin a self-serve manner.
  • In the absence of a security team, label-based automation rules encouraged basicthreat modelingactivities in the development teams which led toincreased awareness about the risk perceptionsof applications. This approach alsohelped to keep the spotlight on the vulnerabilitiesthat are most likely to pose a real threat without creating noise for the development teams.