Org Web Adapter

Editing pages/eng_14488_establish_secure_code_review_process.org

:PROPERTIES:
:ID:       36a4ee87-83da-4ed4-9162-e5c829cdb66e
:ROAM_ALIASES: ENG-14488
:END:
#+title: ENG-14488 - Establish secure code review process

- tags :: [[id:b71b60df-d439-4aa1-8c2c-265707adf8ec][Jira]] [[id:cb7cae00-0f38-4b56-aa5c-d35ca0ea4717][Security Working Group]] [[id:b08ac197-337b-4392-84d5-98eaead61400][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