Joerg Reichelt
6:01 PM
@Yevhen Zavhorodnii
can you explain the scenario? usually risks are created for all assets that are in scope but we don't usually skip rules what adjacent assets (callers, etc.) are out of scope. if you could explain your scenario it would help a lot understanding the reasoning. thanks
Yevhen Zavhorodnii
10:21 PM
What we're saying currently: "if caller is over the internet without VPN or caller is out of scope (even when call make over the VPN)" create risk.
Why is it a risk if call make from caller out of scope if it made over VPN?
Yevhen Zavhorodnii
10:42 PM
Perhaps caller.OutOfScope shall be removed from if condition at all
10:42
Why adding OutOfScope to the caller is adding a risk?
Joerg Reichelt
12:41 AM
I don't think it should make any difference if the caller is in scope or not, I agree with that. this risk should always be created as long as the target is in scope. code backdooring can happen with any code modification, no matter if the caller (source) is in scope of not
12:42
for example, you may pull in code from an open source project. those contributors and the source repo wouldn't be in scope. however, the imported code can still create a backdoor
12:44
similarly, your own developers can introduce a backdoor intentionally (insider threat) or not (by mistake). the developers, their development machine and the repo they push code to would likely be in scope
Yevhen Zavhorodnii 11:40 AM @Joerg Reichelt / @Christian Schneider I believe code backdooring rule is not correct, please take a look at PR with fix: https://github.com/Threagile/threagile/pull/73
Joerg Reichelt 6:01 PM @Yevhen Zavhorodnii can you explain the scenario? usually risks are created for all assets that are in scope but we don't usually skip rules what adjacent assets (callers, etc.) are out of scope. if you could explain your scenario it would help a lot understanding the reasoning. thanks
Yevhen Zavhorodnii 10:21 PM What we're saying currently: "if caller is over the internet without VPN or caller is out of scope (even when call make over the VPN)" create risk. Why is it a risk if call make from caller out of scope if it made over VPN?
Yevhen Zavhorodnii 10:42 PM Perhaps caller.OutOfScope shall be removed from if condition at all 10:42 Why adding OutOfScope to the caller is adding a risk?
Joerg Reichelt 12:41 AM I don't think it should make any difference if the caller is in scope or not, I agree with that. this risk should always be created as long as the target is in scope. code backdooring can happen with any code modification, no matter if the caller (source) is in scope of not 12:42 for example, you may pull in code from an open source project. those contributors and the source repo wouldn't be in scope. however, the imported code can still create a backdoor 12:44 similarly, your own developers can introduce a backdoor intentionally (insider threat) or not (by mistake). the developers, their development machine and the repo they push code to would likely be in scope