Org Web Adapter

pages/eng_14488_establish_secure_code_review_process.org

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