OWASP / www-project-top-10-for-large-language-model-applications

OWASP Foundation Web Respository
Other
499 stars 127 forks source link

cannot access editable source of v2 diagram - www-project-top-10-for-large-language-model-applications/2_0_vulns/artifacts /v2.0 - OWASP Top 10 for LLM Applications and Generative AI - LLM Application HLD - Presentation DLD.jpeg #388

Open idj3 opened 1 month ago

idj3 commented 1 month ago

Remember, an issue is not the place to ask questions. You can use our Slack channel for that, or you may want to consult the following Slack channels:

When reporting an issue, please be sure to include the following:

Steps to Reproduce


What happens?


What were you expecting to happen?


Any logs, error output, etc?


Any other comments?


What versions of hardware and software are you using?


Operating System:Browser:

github-actions[bot] commented 1 month ago

👋 Thanks for reporting! Please ensure labels are applied appropriately to the issue so that the workflow automation can triage this to the correct member of the core team

GangGreenTemperTatum commented 1 month ago

thanks for raising this @idj3 , we do not allow an editable version of the document to prevent unintentional changes into the pipeline

can you please list concerns, errors or improvements for the document in here and i'll collaborate with you?

GangGreenTemperTatum commented 1 month ago

hey @idj3 , ill close this off due to inactivity but plmk if you need anything else! please also see WIP in https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/pull/393 and would love your feedback on this here or in our Slack thread

idj3 commented 1 month ago

Hi @GangGreenTemperTatum , my main comment is that we should consider adding an 'orchestrator' component between the client application and the LLM service - that is where many security safeguards are often concentrated (incl. content moderation, masking, throttling, authentication, etc), grounding (e.g. RAG calluots) and it can span trust boundaries. Also, we should provide general description of the components to include in the final v2 document. I will bring this back in the slack thread to collaborate there.

github-actions[bot] commented 1 month ago

👋 Thanks for reporting! Please ensure labels are applied appropriately to the issue so that the workflow automation can triage this to the correct member of the core team

GangGreenTemperTatum commented 1 month ago

adding comments from our Slack thread @idj3 , let's continue the discussion here for vis of the group and community :)

thanks @Ivan!
> Some of the main features that this capability can include:
i like your points, but im worried this can stray away from a "high level abstraction" which the document serves as, it's not a full blown threat modeling exercise
with that said, any suggestions and are you in agreement here? if we list remediations, where does it end? is it not sufficient to link the OWASP top 10 entries which sub-bullet attack scenarios and remediations? this is the point we are trying to emphasize, but the diagram is to elaborate "where" this can occur in a typical LLM app and trust boundary(ies)
> Also, we should provide general (brief) description for all the components to include in the final v2 document, I thought that was one thing missing in v1.
a callout box, or alternative suggestion you have? or should we refer to the glossary in the wiki?
idj3 commented 1 month ago

I agree that too much detail can be counterproductive, but since LLM10 document aims to provide both vulnerability overview as well as mitigation strategies, IMHO we should have some standardised architecture that guides where/how those controls can be implemented. for example, there can be a lot of prompt manipulation before it arrives to LLM (RAG, masking) which can affect exposure/defenses for a number of vulnerabilities (e.g. 01, 04, 06) lot of organisations are looking to build additional defenses as they tap into external LLMs, where the concept of orchestrator is very relevant (it's something we were discussing at Cloud Security Alliance and I thought it made a lot of sense). on the other hand, there is a great detail on downstream services but not sure what that adds - i may well be wrong though.

re description, imho simple list below the diagram is better than callouts as it declutters the picture. Nothing too detailed, but for example 'plugin' is very generic so some information on purpose, key features (and perhaps who has responsibility) would be beneficial

GangGreenTemperTatum commented 1 month ago

but since LLM10 document aims to provide both vulnerability overview as well as mitigation strategies

sorry, slightly confused here as this is the template for all vulnerabilities, is there something specific for this vulnerability or do you mean in general?

or example, there can be a lot of prompt manipulation before it arrives to LLM (RAG, masking) which can affect exposure/defenses for a number of vulnerabilities (e.g. 01, 04, 06) lot of organisations are looking to build additional defenses as they tap into external LLMs, where the concept of orchestrator is very relevant (it's something we were discussing at Cloud Security Alliance and I thought it made a lot of sense).

i agree, can you annotate an example on top of the current architecture diagram for your understanding of thought logic here? async maybe best with a hectic defcon schedule next week and mainly for me to understand what you "envision this looking like" and open to collaborate on ideas

Nothing too detailed, but for example 'plugin' is very generic so some information on purpose, key features (and perhaps who has responsibility) would be beneficial

i do have to be honest and think we should stick to the default Definitions in the wiki to ascertain a single-source-of-truth and avoid drift, would it help if I added a hyperlink reference here, wdyt?

i really appreciate the feedback and you sharing recent experiences from the CSA also

idj3 commented 1 month ago

@GangGreenTemperTatum : 1 - it was a general comment (not specific for LLM10)

2 - I like the new diagram, I think of "orchestrator" being part of 'application services' or perhaps to sit between app services and LLM. IMHO, RAG should connect to that layer (orchestrator / app services) rather than LLM service directly - RAG typically contains private (enterprise) data and organisations may want to have better control how that is accessed (e.g. to encrich the prompt before it is passed to the LLM); you could see app services and RAG in the same (organisational) trust boundary. wdyt?

3 - i can't access the Definitions page, the link sends me to the diagram

GangGreenTemperTatum commented 1 month ago

@idj3

  1. the diagram is only purposed to identify elements of attack vectors where our top 10 vulnerabilities can be introduced. the topic of remediation items and mitigations is listed in the vulnerabilities themselves (not to overblow the diagram verbosity) or would be done in a separate threat modeling runbook such as STRIDE tables etc.
  2. thanks! i feel that you are suggesting some changes to this portion highlighted(?) can you annotate a simple sketch for my understanding pls?

image

  1. my bad, apologies. i updated my old comment and the link again for reference is here (repo->wiki-><search"definitions">