ASVS
ASVS copied to clipboard
OWASP
V10.2 requirements - cleanup
parent/related issue: #1383
"V10.2 Malicious Code Search" requirements.
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 10.2.1 | Verify that the application source code ~~and third party libraries~~ do not contain unauthorized phone home or data collection capabilities. Where such functionality exists, obtain the user's permission for it to operate before collecting any data. | ✓ | ✓ | 359 | |
| 10.2.2 | Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location. | ✓ | ✓ | 272 | |
| 10.2.3 | Verify that the application source code ~~and third party libraries~~ do not contain back doors, such as hard-coded or additional undocumented accounts or keys, code obfuscation, undocumented binary blobs, rootkits, or anti-debugging, insecure debugging features, or otherwise out of date, insecure, or hidden functionality that could be used maliciously if discovered. | ✓ | 507 | ||
| 10.2.4 | Verify that the application source code ~~and third party libraries~~ do not contain time bombs by searching for date and time related functions. | ✓ | 511 | ||
| 10.2.5 | Verify that the application source code ~~and third party libraries~~ do not contain malicious code, such as salami attacks, logic bypasses, or logic bombs. | ✓ | 511 | ||
| 10.2.6 | Verify that the application source code ~~and third party libraries~~ do not contain Easter eggs or any other potentially unwanted functionality. | ✓ | 507 |
All the "third party libraries" points should be covered by requirements:
- V14.2.4 Verify that third party components come from pre-defined, trusted and continually maintained repositories.
- V14.2.5 Verify that a Software Bill of Materials (SBOM) is maintained of all third party libraries in use.
- V14.2.7 [ADDED] Verify that third party components are sourced separately from internally owned and developed applications.
Or is the message here, that with Level 3 you need to test and code review all used frameworks and components?
Other comments:
- V10.2.1 - phone home is in a way covered that outgoing connections should be limited
- V1.1.5 Verify definition and security analysis of the application's high-level architecture and all connected remote services.
- V12.6.1 Verify that the web or application server is configured with an allow list of resources or systems to which the server can send requests or load data/files from.
- V10.2.2 is good candidate to be some way in V8.3 Sensitive Private Data
- edit: seems that this idea was not first time in my mind (#1201, #1005)
- V10.2.3 - undocumented and hardcoded accounts are related/covered
- V2.5.4 Verify shared or default accounts are not present (e.g. "root", "admin", or "sa").
- V10.2.3 - debugging features are related/covered
- V14.3.2 Verify that web or application server and application framework debug modes are disabled in production to eliminate debug features, developer consoles, and unintended security disclosures.
- V10.2.4, V10.2.5, V10.2.6 - just many different ways to say "malicious code"
There are some points to keep, but a some abstraction and cleanup is needed.
10.2.1 & 10.2.2 are a bit vague. I get the reasoning but without us either adding some examples, this is very handwavy. I agree with the comment that 10.2.2 level 1
I think that the "third party library" part should stay as I think these are L3 requirement with specific and difficult scope.
- 10.2.1 I think this is ok as a L3 requirement
- 10.2.2 is gone to V8.
- I think that 10.2.3 is a lot more comprehensive and wide ranging than 2.5.4. I think it can stay separate
- I would support merging 10.2.4, 10.2.5 and 10.2.6.
