Integrating Security to Agile Development Process by Edwin Tunggawan - Security Engineer Bukalapak @SARCCOM MEETUP http://sarccom.org https://www.meetup.com/Software-Architect-Indonesia

1. Integrating Security to Agile
Development Process

2. $ whoami
● Edwin Tunggawan (@sdsdkkk)
● Currently Security Engineer at Bukalapak (Formerly Software Engineer)
● Mainly focusing on Bukalapak’s server-side and application security
● Basically I’m still a software engineer, just with a focus on security for now

3. How software development used to be in Bukalapak
Idea Initial Design Development
TestingDeploymentMonitoring

4. How software development currently is in Bukalapak

5. Then vs Now
Then Now
Not much parallelism, small team. Huge team broken down to small teams for
parallel development.
One engineer can keep track of changes
and ongoing projects in the company.
One engineer is unlikely to be aware of
whatever changes are made by other
teams.
Monolithic. On progress in moving to microservices.
Not much external security threat, any
vulnerability is unlikely to be a big problem
as long as it’s solved ASAP.
How many invalid bug bounty and breach
reports are we getting on our security
mailing list every day again? How about
that media coverage regarding our
ImageTragick vulnerability?

6. We need more effort regarding security
● The system’s becoming so complex, it’s easy to miss what’s going on in other
teams’ development activities
● The company’s getting more well-known that any small security incident could
have a huge brand impact
● Any design/implementation problem in the system could be so much harder to
fix as time goes on in a system this big

7. So, basically we’re moving towards secure SDLC
Image from https://www.owasp.org

8. Bukalapak’s development values
● Execution speed matters
● Ship it ASAP
● Data-driven

9. What we value in Bukalapak’s security team
● Work without compromising the development values
● Preventing development mistakes instead of fixing them

10. So...
● We need to ensure the security of the software without adding unnecessary
slowdown in the development process
● Too much slowdown is bad

11. Integrating security to the development process
● The security engineers need to be actively involved in development
● We only have two security engineers and one security analyst, and around
200 people on product + engineering for development
● We need to work in a way that scales well

12. How we’re doing it
● Conducting security code reviews and blackbox tests to the whole application
● Conducting reviews on libraries and services
● Acting as advisors in the development stage
● Automating security tests

13. Security code reviews + blackbox tests on apps
● Monthly code audits
● Reviews & blackbox tests by request
● We’re keeping notes of the mistakes we found and summarizing them in a
series of internal secure development guide articles
● Raising awareness in the internal product + engineering tech talks based on
the common high-value mistakes we found

14. Reviews on libraries and services
● Sometimes the source of the problem is not the apps
● Some of the libraries and services are developed internally, so the
responsibility is the company’s whenever there’s a vulnerability there

15. Advising development
● Some features need more attention regarding security
● We’re reviewing the requirements and advising revisions if there’s any security
issues in it
● We’re advising how the features need to be implemented in order to be secure
● Features that’s considered to be safe don’t need special advisories, as long as
it complies with the secure development guide

16. Automating security tests
● We have automated tests with unit testing and integration testing
● Why not add security tests on it?
● Currently on the way for implementation
● Expected to detect vulnerabilities early and enforcing secure development
practices more strictly

17. Our ideal secure SDLC
● Security team can be involved in any stage of development as needed
● Optimized for development speed
● Using automation whenever possible

18. What we expect in the future
● Less security vulnerability caused by the lack of security perspective in the
design and implementation stage
● Less security vulnerability caused by the lack of awareness on the engineer’s
side, especially after automated security testing is enforced

19. Thank you