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?
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
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
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
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>
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!
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 !!