- ID
- 36a4ee87-83da-4ed4-9162-e5c829cdb66e
- ROAM_ALIASES
- ENG-14488
ENG-14488 - Establish secure code review process
- tags :: Jira Security Working Group 15Five
Categories
Configuration and deps
settings
Settigns and pacakges.json
squad_sandbox
tools
circleci
Authentication
api
account
saml2
devops
Authorization - who can see what
additional_reviewers
core/user
group
core/encryption
Data export
salesforce?
core/csv_export
core/excel_export
core/exports
Data import
api
bulkimport
hris
scim
sftp
Notes
+ Go thorugh layers of app which connect
+ SAML integration, high-risk because someone using that data could take over an account
+ Try to be more modular about how you approach it
+ About data flow ...
+ Configuration files could be high risk
+ Data disclosure, sharing data through the app, make sure it's reaching the audience
+ Data visibility
- Who should see what?
- Within the app and the full lifecycle
+ Go ahead and ignore the frontend for now, focus on Backend
+ Need think about what would be important in the context of code review
+ Which areas during reviews would be most important part from security persepctive
+ `settings`
+ uploaded data, CSV, public API
+ Private API
+ Data genereation into files, helper classes to protect customers from injections in CSV and Excel
+ Not fulling protecting case where customers generate lots of extra files at these same time
+ Recommend starting with writing a guideline with a policy of the types of code
+ Assign security working group when they meet particular criteria
+ File upload, user management, data transformation, file management
+ Once we categoryize risks, share with others
+ Ask if it's useful and
+ Key changes in auth process,
+ Anything having to do with user auth or management
+ Pulling from customer endpoints is an area of risk
+ Need specific examples, user auth is the risk, so we're requiring you to ask for a PR
+ Want to do the work very well and get specific, but it's hard to do that from the start
+ We should have other engineerrs review the places we've found and solicit input from other engineers
+ Maybe people already know places, but don't have a place to canonicalize the information
+ Not easy to give recommendations for secure code right away
+ But once you start to see patterns like places for injections, you can refine the quality of your feedback
+ Patterns may appear for writing more secure code
+ Insufficient logging and monitoring, user accounts & data transformations
+ How can we know if LDAP or some other auth mechanism is being used to
+ Create high level documentation