Static analysis security tools are part of Qiwi's Secure Development Lifecycle (QSDL) process to automate security testing. The QSDL was implemented to address issues like low test coverage, vulnerabilities found after release, and a lack of security resources. It incorporates threat modeling, security reviews, static application security testing (SAST), fuzz testing, and penetration testing at various stages. SAST tools work by parsing code to build an abstract model and check for vulnerabilities, but have limitations with dynamic code, dependencies, and unsupported languages that require additional configuration.

1. Static Analysis Security Tools
in
QIWI Secure Development Life Cycle
Ivan Elkin
Application Security Expert
Qiwi

2. ~$ whoamI
- Qiwi, Application Security
- Developer
- Vulners.com team
- JBFC Member 😀

3. More than Two Years ago...

4. Qiwi Development Lifecycle
Business
QA
Support
ISEC
TASK
DEV
Testing
Regress
testing
Bug
Development
Functional
bug
New
TASK
Release

6. Qiwi OLD Development Lifecycle
Business
QA
Support
ISEC
TASK
DEV
Testing
Regress
testing
Release
Bug
Development
Functional
bug
New
TASK
ISEC
ISEC tests

7. Qiwi OLD Development Lifecycle
Testing
Regress
testing
Release
Functional
bug
New
TASK
ISEC
ISEC tests
First standard steps were:
- Periodical Pentests
- Bug bounty program
- Deep dive into code of each
release
- Some Fuzz scans on several
projects
- ….
- ….
- Lots of other standard sec-staff

8. Qiwi OLD Development Lifecycle
Testing
Regress
testing
Release
Functional
bug
New
TASK
ISEC
ISEC tests
But:
- Low test coverage
- Manual testing takes time
- You have no time
- Some functionality you didn’t
hear before bug found
- More than 30 big
projects/applications!

9. Sometimes it was like a fire
fighting…
- Hackerone
- Real Attacks
Qiwi OLD Development Lifecycle
First hours after BugBounty program open

10. Task:
- More than 30 projects and applications
- 6 main programming languages
- Horde of programmers
- Infinity of business tasks
- 1-2 AppSec specialist
…
How to protect the internet from ourselves?

11. Something should be changed… we want SDLC!
So we expected:

12. Secure Development Lifecycle by MS

13. Secure Development Lifecycle by MS

14. Secure Development Lifecycle by MS

15. Secure Development Lifecycle by MS

16. Automate all the things!!

17. Things we’ve done

18. QSDL
Business
QA
Support
ISEC
TASK
Refactoring
Testing
Regress
testing
Release
Bug
Development
Functional
bug
New
TASK
Scanners
ISEC
SDLC

19. SA
QA
TRBL
ISEC
TASK
Refactoring
QSDL - New Task
In case of new task
- Threat modeling
- First security review
- If task relates on side project, makes security
review and testing of it

20. Testing
Bug
Programming
QSDL - Design and Programming
- Now programmers know what does it mean:
XSS and so on, so design and development
with a concept of secure programming
- Trigger on TeamCity test-deploys will start
SAST after programmer merge pull request to
release-branch
- Emailing about new found vulnerabilities by
SAST
- Automotive tasks in Jira
- Anytime review of previous scans with detailed
inspection of scan alert
This concept is actual for project with short lifecycle (release several time in a week)

21. Testing
Regress
testingBug
Programming
QSDL - Pre-Release Cycle
- Verification by SAST, trigger on
TeamCity before release deploy
- Auto Fuzz-tests
- Manual pentests, extra scanners
- Security code-review
This concept is actual for project with long lifecycle (release one time in a two week)

22. QSDL - Release
- In the context of a short release cycle we check the
opportunity of release (the results of the intermediate
Autotest), and provides recommendations for changes
- Monitoring of releases by ourselves
Release

23. QSDL
SA
QA
TRBL
ISEC
TASK
Refactoring
Testing
Regress
testing
Release
Bug
Programming
Functional
bug
New
TASK
Scanner
ISEC
SD

24. SAST

25. Static code analysis tool:
- searching security
bugs by creating DOM-model of
program code calls
- one of key spec is
searching of second order
injections, stored injections and
so on by walking through DOM-
tree
- Some Vendors sells it
as a main tool of SDLC flow

26. Other good features
- Best Coding Practice
- Deprecated methods
- Syntax sugar
- Seraching of logic errors => performance improvement
- Infinite loop
- Switch without Break
- Inline If
- Buffer size which depends on user input
- Empty exceptions
- Syntax errors
- Bad Classcasts

27. Not so ideal...

28. CX

29. SAST Scanner - Under the hood
1. How to start scan

30. Vendor told:
“.. Scanner should receive only clear
code”
And he is right!
Ok, but what about
Libraries
Dependencies
Maven
Dynamic Code Injection
SAST Scanner - Under the hood

31. - source pulling
- compile
- code injecting
- custom flow
- monitoring
- mail
- tags
Control Server
SAST Scanner - Under the hood
Welcome! Project which compress project for another project to scan
second project!

32. Common process of deploy and scans
- Developer start task in TC (hook, or manual)
- TC build-agent start client-script which send request about branch to Control
Server (CVS, brunch, build-id)
- Control Server
- Fetch source from VCS
- Compile code
- Fetch dependency from VCS or Maven (if you have sources)
- Make own Dependency injection flow (if SAST not support it)
- Make own program langs flow
- Monitoring everything works
- Results
- TC tags for builds (if build is vulnerable, we can’t pass it to release)
- Email to ISEC and Developer
- Monitoring everything done

33. SAST Scanner - Under the hood
2. I want to see full flow from
client to server

34. So, I Expect

35. Vendor told:
“.. Each part of code should be
independent ..”
And he is right!
SAST Scanner - Under the hood
JS JAVA PLSQLJAVA

36. SAST Scanner - Under the hood
3. I want to write dynamic code!!!

37. All we are love a dynamic code with
Dependency Injections
Generics and so on
public interface FieldsChanger {
Collection<FormField> change(FieldsChangerDTO fieldsChangerDTO);
}
<bean id="fieldsChanger"
class="ru.mw.webui.person.form.changer.ExtendableFieldsChanger">
<constructor-arg>
<map key-type="ru.mw.webui.person.data.FieldSetRule">
<entry key-ref="mainFieldSetRule">
<bean class="ru.mw.webui.person.form.changer.PlaceHolderFieldsChanger"/>
</entry>

38. Vendor told:
“.. Not all code can be static analysed ..”
And he is right!

39. But we can do: dynamic -> static
public interface FieldsChanger {
Collection<FormField> change(FieldsChangerDTO fieldsChangerDTO);
}
public interface FieldsChanger1 {
Collection<DefaultFormField> change(DefaultFieldsChangerDTO fieldsChangerDTO);
}

40. SAST Scanner - Under the hood
4. I want to write on Scala, Go and use all
new Frameworks!

41. Vendor told:
“.. You are so modern
… everything for your money! ..”
And he is right!

42. SAST Scanner - Under the hood
5. It found only one XSS and 100500 strange
things!? What happen???

43. Vendor told:
“.. Each project is unique
and each has own bicycles! ..”
And he is right!

44. Be ready to read tons of code!

45. Bad news:
- while we set up scanner, some guys found two real good bugs first
:(
Remember:
- look into all types of bugs some could be signed as low-level
- some frameworks still not supported out of the box

46. So,
To start it
- Put all your libraries to own CDN
- Write 20k lines of code for Control Server and Client
- Invent your own compiling system
- Write your own monitoring system
To make code ‘scannable’
- Read kilometers of code
- Find each input and output points
- Write more than 100 own rules of scans

47. Achieved:
- Found about 25 bugs in main projects
- XXE, RCE, XSS, SQLi
- 32 projects were added to autoscan
- Full SDLC in you company!
- It was made by 2 people !!

48. Thanx!
Questions?
@vankyv3r